Compare Struts1 And Struts2

Comparing the Struts 1 and Struts 2 Web Application Frameworks By Michael Klaene Go to page: 1 2 3 4 5 6 Next Because the Struts web application framework was initially released at the beginning of this decade, developers have utilized it to construct many thousands of applications. Struts was, and still is, the most popular framework for building Java-based web applications. Though not without its flaws, Struts simplifies the construction of robust and maintainable web-based software. Today, there are probably twice as many applications using Struts than there are those using all other competing web frameworks combined. It is a tribute to Struts that so many succeeding frameworks, such as JSF (JavaServer Faces), borrowed many of their concepts directly from Struts. Struts is far from perfect, however, and in recent years developers have increasingly begun to turn to alternative solutions. To keep pace with developer demand, the Struts team released a major update to the framework; it's generally known as 'Struts 2'. The purpose of this article is to provide Struts 1 developers an overview of how Struts 2 works by looking at code. You will look at a sample application twice, once as a Struts 1 application, and then a second time as a Struts 2 application. You won't be able to cover everything, but it should be enough to get you started with Struts 2.

Background Struts was first released in 2001. Its primary contributor was Craig McClanahan. Prior to Struts, web applications were often a jumbled mix of Java scattered throughout JSP(JavaServer Pages) scriptlets, Java Servlets, and various Java classes. Applications produced in this haphazard manner were typically hard to test and even harder to maintain. Struts promoted an MVC (Model-View-Controller) architecture. With MVC, developers were able to produce more modular code that was flexible enough to allow an application to grow. The MVC style of development has stood the test of time and has proven itself to be a successful approach for constructing web applications. In the last several years, competing frameworks have emerged to address some of Struts' inadequacies. The Struts community began work on a nextgeneration Struts to address some of these problems. Another framework, called WebWork, had in the meantime gained some notoriety as a viable successor to Struts. Finally, the Struts team and WebWork decided to join forces; this union led to the emergence of Struts 2. Struts 2, in many respects, represents a significant improvement over Struts 1.

Struts 1 Walkthrough As previously mentioned, this article will attempt to provide a comparison of Struts 1 and Struts 2 by comparing the code used to develop the same application with each framework. Some cursory knowledge of Struts 1 is assumed. The sample application you will create is called 'defect-tracker'. It allows users to record application defects and developers to record resolutions to those defects. The application is trivial with the most basic requirements, but it should provide sufficient opportunity to cover basic features common to most all web applications. To begin a Struts 1 application, the first file you need is the web.xml configuration file. The web.xml file must be modified for Struts 1 so application URI requests can be routed to a Struts controller: <servlet> <servlet-name>action <servlet-class>org.apache.struts.action.ActionServlet <param-name>config <param-value>/WEB-INF/struts-config.xml 2 <servlet-mapping> <servlet-name>action *.do URI requests matching the pattern '*.do' are received by the Struts ActionServlet. ActionServlet finds the Struts Action mapped to this request as specified in the struts-config.xml configuration file. The ActionServlet and Action objects comprise the 'controller' portion in the MVC architecture of a Struts application. To transport data between Struts Actions and the 'view', typically implemented as JSPs, Struts uses ActionForm objects. ActionForm objects represent the 'model'. When a user submits a form, the ActionForm, along with its data, is passed to the Action's execute method. The Action might validate the data, and then invoke any necessary business logic, which, ideally, will be encapsulated in another layer that is completely unaware of Struts. Once business logic executes, the Action transfers control to a view specified in one or more ActionForward objects, which are also configured in struts-config.xml. ActionForward entries represent the possible outcomes of an Action. They can be defined for each Action or globally to apply to all Actions. A glimpse of the struts-config file is provided below. The defect-tracker application has two sets of Actions and ActionForms. One set concerns the listing of existing defects. The second set addresses the manipulation of defect data, typically referred to as 'CRUD' ('Create-Update-Delete').

struts-config.xml The last two entries in struts-config declare a properties file for displaying application messages and labels, and a separate configuration file to be used to add validation rules for the ActionForm objects in your application. The defect-tracker application has a single domain object, Defect, that represents a system defect. Upon startup, the user is redirected to 'list.do', which maps to the DefectsList Action object's execute method that will retrieve a list of defects.

DefectsList execute method public ActionForward execute( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) { DefectsListForm defectsListForm = (DefectsListForm) form; //Get data from business layer and assign it to the form //object... //... return mapping.findForward("list"); } The execute method obtains the application data and assigns it to a Collection of Defect instances using the setDefects() method on ActionForm DefectsListingActionForm class. DefectsListForm's Defects property private List defects; public List getDefects() { return defects; } public void setDefects(List defects) { this.defects = defects;

} The defects.jsp file utilizes Struts 1 tag libraries to display these defects and to display labels and messages from a .properties file that you declared in struts-config.xml.

defects.jsp displays all defects

The user can choose to add, edit, or delete a defect. When the user wants to edit a record, for example, the handler first obtains the ID from the HTTPServletRequest, which is passed as a parameter to the Action's execute method. The execute method then will invoke a method in the business layer to obtain the defect, and then it transfers to an editable form which will be populated with data. When adding a new defect, a blank form appears. Because it does not make sense to allow a user to resolve a defect they have just entered, the add form provides only a subset of fields. addDefect.jsp to enter information about new defects

editDefect.jsp for updating defects

Struts 1 does not always handle the conversion of input strings very well so sometimes the developer needs to convert form data before passing it to a domain object. The DateConverter class accomplishes this for date fields. After a successful add, edit, or delete, the user is returned to the list again. The first Action we saw, DefectsList, had its 'execute' method automatically invoked. Sometimes an execute method is all you need, however, in order to help developers consolidate related actions in a single Action object, Struts 1 offers the 'DispatchAction' class. DispatchAction uses the 'method' request parameter to tell the Struts Action which method to invoke. So,instead of 'execute', we can define methods like 'add', 'edit', and 'delete' to handle each type of request. In order to use DispatchAction, your Action object needs to extend DispatchAction (not Action) and define a form parameter that identifies the method to invoke. The method for deleting a defect from DefectsAction is shown here:

DefectsAction's delete method public ActionForward delete( ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) { long id = Long.parseLong(request.getParameter("id")); //Invoke business layer to delete the object using the id... return mapping.findForward("list"); }

Struts 1 developers use the Apache Commons Validator framework to validate data. To enable validation, you must register the Validator plug-in in the struts-config.xml file, and then make sure your own ActionForms extend ValidatorForm instead of ActionForm. You can declare validation rules in a validation.xml file. For example, the validation.xml file you use states that a defect's description is required. The 'validate' method is invoked by the Action before saving a record. When the user does not provide a description, the Struts ActionErrors collection is populated and its contents displayed on the view page with the help of an tag.

<arg0 key="defects.description"/>

Validating the form upon save ActionMessages errors = form.validate(mapping, request); if (!errors.isEmpty()) { saveErrors(request, errors); Validation error message is displayed on addDefect.jsp

That just about wraps up your look at the Struts 1 version of defect-tracker. Hopefully, it will have been mostly a review for you. However, before you move on, it is obvious that you have not really produced a working application. Struts provides the web framework, but what about the portion of the application where you implement your business logic and save data to the database? Struts cannot help with this piece. Business logic is best kept in a separate business layer implemented with EJBs (Enterprise JavaBeans) or plain Java classes that have no concept of Struts. One popular framework for orchestrating the business layer logic is the Spring framework. Spring, for those unfamiliar with the framework, is essentially a dependency injection framework that declares Java classes and their dependencies in a configuration file. At runtime, instead of having to obtain dependent objects manually, they are injected for you. Beyond this, Spring offers numerous other useful features and integration points for many other Java frameworks and toolsets. For defect-tracker, I have chosen the Spring framework primarily for two reasons. First, Spring is very popular and integrates well with Struts. A great many Struts 1 applications already use Spring. Secondly, Struts 2, as you will see, is even more closely tied to Spring, making an even stronger argument for its use with Struts. Because so many Spring developers use Struts, Spring offers supporting classes for working with Struts 1. You have two options: Use Spring's ContextLoaderPlugin to manage injections or use Spring's ActionSupport classes to obtain Spring's application context. Both options are fairly easy to implement. This article is about Struts, so I will not dive into the details of the business and data tiers of the application, but I have implemented these two layers using Spring, with the help of the Hibernate framework for persistence. Here, briefly, are the steps I have used to wire Spring to the defect-tracker application. First, the Spring configuration file needs to be mentioned in the web.xml file: <param-name>contextConfigLocation <param-value>/WEB-INF/application-context.xml

<listener> <listener-class>org.springframework.web.context. ContextLoaderListener Using Spring's ActionSupport classes is the simplest approach and the one used here. You obtain a Spring-managed bean in your Action method and use it to invoke business logic. For example, in the save method on the DefectsAction class, you obtain Spring's context, and invoke the methods provided in an implementation of the DefectManager business interface: ... WebApplicationContext ctx = getWebApplicationContext(); DefectsManager mgr = (DefectsManager) ctx.getBean("defectsManager"); mgr.saveDefect(defect); ... DefectManager is where any business rules should be coded. To illustrate this approach, when the user enters a resolution to a defect, the DefectManager will automatically audit that user (obtaining an actual name in a real application of course), and set the Defect's isResolved flag to 'true'. Then, Spring calls upon Hibernate to handle the necessary database interaction. Click here to view the complete 'Springenabled' Action classes: DefectsList and DefectsAction.

On to Struts 2... Now that you've seen Struts 1, it's time to have a second go around at defect-tracker, this time using Struts 2. My goal is to not deviate too much from the original design to to keep comparisons valid. To implement defect-tracker as a Struts 2 application, the first thing you will need to do is modify the web.xml file. Struts 1 used a Java Servlet called ActionServlet to intercept requests matching a specified URI pattern ('*.do' by default). Struts 2 opts to use a Servlet Filter instead. The default extension for Struts 2 is not "*.do" but "*.action". This extension does not need to be specified in the Filter mapping, but will be assumed. It can be overridden, as many of Struts default properties can by editing a 'struts.properties' file and placing it in the classpath. Due to the different ways that each version of Struts maps requests, developers should have no problem using both Struts 1 and Struts 2 together in the same application if they choose. Filter mappings in Struts 2 web.xml struts2 org.apache.struts2.dispatcher. FilterDispatcher struts2 /* Struts 1 utilized the 'struts-config.xml' file for Struts configuration. For example, the struts-config is where a developer maps path names to Actions, defines ActionForms that go along with those Actions, and specifies ActionForwards for different types of Action outcomes. Well, a lot has changed in this area in Struts 2. For starters, Struts 2 replaces struts-config with a file called 'struts.xml'. The 'struts.xml' file can be placed anywhere in the classpath. Peering into struts.xml, you will notice some big changes. First and foremost, ActionForms are gone. Struts 2 places no restrictions on where a developer stores a page's data. For example, you can pull the form data directly from the Action class (Actions have stuck around for Struts 2). Struts 2 replaces ActionForward objects with Result objects. Similar to Struts 1, an Action returns a string result that is matched against an entry in struts.xml. Below is how your two Actions in defect-tracker are configured in Struts 2. Note the various changes in element names too. For the most part, these new element names are fairly intuitive of what they represent. <struts> <package name="default" extends="struts-default"> /pages/defects.jsp /pages/editDefect.jsp

list.action In struts.xml, developers group related-actions into a 'package'. You are simply using the default package here. However, if you decided to create a packaged called 'crud' with a similarly titled 'namespace' attribute, URI requests for Actions in that package would take the form of '/crud/*.action'. Developers can define constants here to override some default settings in the Struts 2 framework. Looking at the Action declarations, you will notice that a single result can be specified without a name. Struts 2 assumes this default entry to be the 'success' result and there is no need to specify it. If you will recall, you used a Struts 1 DispatchAction to handle the multiple CRUD events for a defect. There is no need to extend DispatchAction (in fact, DispatchAction does not exist in Struts 2). Rather, a wildcard/placeholding mechanism can be used instead to transfer control to a specific Action method. For example, in the Struts 2 DeffectsAction, a URI of 'action_go' will result in the invocation of a 'go' method on the relevant Action class. The 'list.action' URI request maps to your Struts 2 version of the DefectsList Action class. Here is the code: package web; import business.DefectsManager; import com.opensymphony.xwork2.ActionSupport; import java.util.List; public class DefectsList extends ActionSupport { private List defects; private DefectsManager defectsManager; public List getDefects() { return defects; } public void setDefects(List defects) { this.defects = defects; } public void setDefectsManager(DefectsManager defectsManager) { this.defectsManager = defectsManager; } public String execute() { this.defects = this.defectsManager.getDefects(); return SUCCESS; } }

Compared to the original DefectsList Action class, I think you will agree the code here is much cleaner. Extending the Struts 2 ActionSupport class is not a requirement but it does provide access to many useful methods and constants, such as the SUCCESS constant you are using as a result. Contributing to the leanness of this code is the fact tha the execute method, which used to require four parameters, now has zero parameters. One of these parameters was for the ActionForm and ActionForms that are no more. But besides that, the remaining parameters are missing because Struts 2 uses the Spring framework internally to inject necessary dependencies like the HTTPServletRequest object at runtime, when it is needed. Along with dependency injection, an important concept in Struts 2 is its use of Interceptors. Essentially, Interceptors are Java classes provided by the Struts 2 framework that allow you to perform logic before and after Action executions. Several Struts 2 Interceptors are provided out of the box, but you can also create your own. Typically, to use an Interceptor, an Action class will implement the appropriate interface; then, this will alert the Interceptor associated with that interface that it has a job to do. Because Spring is built into Struts 2, injecting Spring beans is as easy as creating a setter method for the Spring-managed bean. Struts 2 will inject this dependency automatically at runtime. Another option available is to declare Struts Action classes as Spring beans in Spring's configuration file. Read the Struts 2 documentation for more information on this. Here is the result of your Struts 2 'list' action, defects.jsp. The Struts 2 tag library is easier to use and much more powerful than those provided in Struts 1. One noteworthy feature of the tag library is its use of themes. Depending on which theme you set, the tags will generate a good deal of stylized markup for you, further reducing the amount of page clutter. You can set the theme globally and can override it for individual tags, as I have done here to keep the generated output similar to the Struts 1 version of defect-tracker. Here are a few examples of Struts 2 tags found in the list page:

<s:url id="editLink" action="action!input"> <s:param name="id" value="%{id}" /> <s:date name="submittedOn" format="yyyy-MM-dd hh:mm" /> DefectsAction in Struts 2 looks even cleaner than DefectsList given the number of methods it contains. There are no ActionForms to contend with, no lengthy method APIs, and you can access your Spring business layer with ease, just as you did in DefectsList. Here is the code in its entirety: package web; import import import import import import

business.DefectsManager; business.data.Defect; com.opensymphony.xwork2.ActionSupport; javax.servlet.http.HttpServletRequest; org.apache.struts2.interceptor.ServletRequestAware; org.aspectj.weaver.patterns.ThisOrTargetAnnotationPointcut;

public class DefectsAction extends ActionSupport implements ServletRequestAware { private Defect defect; private DefectsManager defectsManager; private HttpServletRequest request; public Defect getDefect() { return defect; } public void setDefect(Defect defect) { this.defect = defect; } public void setDefectsManager(DefectsManager defectsManager) { this.defectsManager = defectsManager; } public void setServletRequest(HttpServletRequest httpServletRequest) { this.request = httpServletRequest; } public String input() { if (request.getParameter("id") != null) { long id = Long.parseLong(request.getParameter("id")); this.defect = this.defectsManager.getDefect(id); } return INPUT; } public String delete(){ long id = Long.parseLong(request.getParameter("id")); this.defectsManager.removeDefect(id); return SUCCESS; } public String save() { this.defectsManager.saveDefect(this.defect); return SUCCESS; } } As with Struts 1, you need to access the HTTPServletRequest to obtain the defect's IF. To obtain this ID, DefectsAction utilizes what is probably the most common Struts 2 Interceptor you will use. You simply implement the ServletRequestAware interface and add a setter method for the request and the framework will make sure you have it when you need it. The 'input' method in this class replaces the add and edit methods in the previous version of the application. If an ID is present, you query for the defect; otherwise, you simply continue on to the result. This leads you to editDefect.jsp. In Struts 2, if the page is passed a reference to a null object, it will automatically create a new one. This is exactly what you want when creating a new Defect object.

Data form for creating and modifying defects <s:form action="action!save" method="post" > <s:hidden name="defect.id" value="%{defect.id}" /> <s:textfield label="%{getText('defect.description')}" name="defect.description" value="%{defect.description}" size="100" maxlength="200" required="true" /> <s:select label="%{getText('defect.priority')}" name="defect.priority" value="%{defect.priority}" list="#{'1':'1','2':'2','3':'3','4':'4'}" />
<s:if test="defect.id > 0"> <s:textfield label="%{getText('defect.resolution')}" name="defect.resolution" value="%{defect.resolution}" size="100" maxlength="200" />
<s:submit value="%{getText('defect.editrecord')} " /> <s:submit value="%{getText('defect.cancel')}" action="list" /> Struts 2 utilizes the OGNL library to provide support for expressions. This allows you to efficiently display labels and model data together. The Struts 2 tag can be used to toggle the display of the resolution field, depending on whether an existing id can be found. The form's action attribute specifies 'action!save', meaning the 'save' method will be invoked upon submit. Finally, I will quickly discuss validation in Struts 2. Struts 2 uses the validation framework provided by WebWork. It too offers a similar declarative method for validation, but it is a more fine-grained approach. You have two choices, validate on a per-model basis or peraction. To validate at the Action level, you would simply create a file that takes the name {your action}-validation.xml and place it in the same package as the Action class. To validate at the model level, you would create a similar file that takes the name of the model object. A common approach is to validate at the model level, as you have done in the file Defect-validation.xml, then direct your Action validation file to validate per the rules in the model's validation file: Defect validation <message key="errors.required"/> Action validator, delegates validation to the model with the 'type="visitor" ' attribute <param name="appendPrefix">false <message/> In Struts 2, validation is enabled by default. There is no 'validate' method to invoke. Struts 2 also avoids firing validation on Actions that return 'input' so you can avoid writing code to suppress validation when it is not desired. There is a similar set of tags in Struts 2 for displaying validation error messages.