Converting Struts 1 to Struts 2

The easiest way to upgrade Struts 1 is to convert it to Struts 2. Struts2 is still maintained by Apache Organization, and is considered free of security vulnerabilities.

Overview of converting Struts 1 to Struts 2

Struts 2 is actually not based on Struts 1. It is based on a web application called WebWork. The two framworks are very similar so this heritage does not have a huge impact. However, Struts 2 is definitely not backward compatible with Struts 1 so quite a few changes are needed to port your application from one to the other. There are fewer differences going from Struts 1 to Struts 2 than when going from Struts1 to Spring MVC, because Struts 2 still uses action classes and an XML file for the mappings, whereas the preferred SpringMVC model uses a controller class containing annotated methods for mappings. Furthermore, going to another server side MVC is a much less labor intensive upgrade, than going to completely different paradigm like a thick Json client, like View.js.

At least with going to Struts 2 or Spring MVC you can keep your actions and jsp pages in tact along with all their business logic as well as preserve the UI flows. Going to a Json thick client would mean tearing everything apart because you would move your controller logic to javascript and have to change all your business logic into services. It wouldn't even make sense to try to preserve your UI flows because you would be making a mess out of paradigm that controls UI in a different way. Struts 2 does support Spring integration so it is not like you miss out on Spring when you go to Struts 2. I also consider Spring MVC to be a solid framework so there is nothing wrong with converting to that either.

Here are the major differences when going from Struts 1 to Struts 2.

Bean scope - Struts 2 defaults to beans only living as long as the request. This is probably a good thing because leaving a bunch of junk hanging out in the session was a common mistake in Struts 1. Struts 2 does provide ways to keep things living longer but they are one offs and I think it will mean fighting against the way the framework was intended to be used. There are some ugly implications of this new behavior though. I found it made implementing back button functionality much more difficult because you can't jump back to the previous jsp because the bean that supported it is gone now. Using WebRocketX for your front end would of course eliminate this issue. Struts 2 also has an ActionContext which also only lives as long as the request. This is another thing that takes a little getting used to. Beans are also mapped to the Actions using java rather than in the XML file. Struts 2 Model Driven Action
New Action objects for every request - In Struts 1 an Action was a servelette. This means that it lived continuously on the server and wasn't thread safe. In Struts 2 a new action object is created for every request. The Struts 2 documentation sells this as an improvement because it makes the Action a POJO and works better for mocking. I don't really buy this explanation. I think it was just the way that WebWork was written and they didn't feel like rewriting that code. It seems to me that a Servlet will perform better because you aren't constantly newing up Action objects, and I never found the thread safeness or the mocking of it to be problem. What this means for your code is you no longer have the utility parameters coming into your execute method like before. I like to solve that by making an Action parent that all of my actions extend and creating an overridden execute method in it that gets fed the same objects. It also makes doing any common things like setting the locality into the ActionContext, on every request, something you can put in the parent execute method. Well, I guess I destroyed their whole POJO thing. Oh well. It makes the conversion much easier.
Using Interceptors for Authorization - In Struts 1 the authorization was in the mapping. Now you have to add it to the mapping as interceptors. More details on that below.
New tags - This was probably the most painful change. The old Struts 1 tags will not work in Struts 2. However, JSTL works in both. So if you are lucky enough to have used JSTL in Struts 1 then you don't have a problem. I recommend converting those Struts1 tags, with the exception of the tag for Resource Bundle rendering, into JSTL tags instead of using Struts2 tags. If you use JSTL then you can also go to Spring MVC some day if you like.
Field Error instead of Action Error - You will have to convert all Action Error instances into Field Errors. They are more or less the same thing just different syntax. More details on that below.
Tiles attribute names - The attribute names in the tiles are different. Other than that tiles works the same. Seems like a dumb difference. I think tiles is "yuck" anyways. Why not just use include directives and by pass all of the complication of tiles, but if you are stuck with tiles for now, this is one spot where going to Struts 2 will be better than going to Spring MVC.

Struts 1 to Struts 2 Conversion Cheat Sheet

Well, I couldn't put everything here but this will help anyone converting. I assume that the developer will want to go from Struts 1 tags to JSTL.

                                
-- Struts 1 dispatcher actions are converted by making a case statment or if statements 
   Example of code inside the action execute method

    String action = request.getParameter("action");
                                
    switch (action) {
        case "edit": return editCalendarSettings( request,  response, httpSession);
        case "save": return quickAlterRates( request,  response, httpSession);       
        default: return null;
    } 
    
-- action errors to field errors

    ActionErrors errors = new ActionErrors();
    errors.add(ERROR_KEY, new ActionError("error.myErrorkey"));
    saveErrors(request, errors);
    
    addFieldError(ERROR_KEY, getText("error.myErrorkeyt"));
    
-- Standard jsp includes

    <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core_rt"%>
    <%@ taglib prefix="s" uri="/struts-tags"%>
    
-- jsp conversion of label (internationalized in resource bundle)

    <bean:message key="label.save"/>
    <s:text name="label.save"/> 
    
-- jsp conversion of label with params

    <bean:message key="label.warning" arg0="arg0" arg1="arg1"/>		
    <s:text name="label.warning"><s:param value="#foo"/><s:param value="#bar"/></s:text>
    
-- jsp conversion of form

    <html:form action="Abc" styleId="myForm">
        
        <html:hidden property="myHiddenField"/>
        
        <html:text name="systemDateForm" property="date"/
        
        <html:checkbox styleId="mycheckbox" property="mycheckbox"/></td>
        
        <html:select property="myFieldName">
            <html:options collection="myform.mylist" property="value" labelProperty="description" />
        </html:select>
        
    </html:form>

    <form name="myForm" id="myForm" action="/Abc.do" method="post" >
    
        <input type="hidden" name="myHiddenField" value="${myform.myHiddenField}"/>
          
        <input type="text" id="date" name="date" value="<fmt:formatDate pattern="${shortDatePattern}" value="${systemDate}"/>" />

        <input type="checkbox" id="mycheckbox" name="mycheckbox" value="true" <c:if test="${myform.mycheckbox}">checked</c:if> />  *see note below
        
        <select name="myFieldName">                            
            <c:forEach items="${myform.mylist}" var="myItem">
                <option value="${myItem.value}" <c:if test="${myform.myFieldName == myItem.value}">selected</c:if> >${myItem.description}</option>
            </c:forEach>            
        </select>
                    
    </form>
	
    *Checkbox fields are weird in web browsers because they aren't sent to the server when not checked.  
    This forces developers to do strange things to make them be recorded when both checked and unchecked.
    
    Since in struts2 the formbean generally doesn't persist longer than a request, so you can put boolean primitives in your 
    formbean to receive checkboxes and these booleans will naturally default to false.  
    So, now all you have to do is hard code your checkboxes to a value of "true".  
    Make sure this is the value attribute not the checked attribute.  Then if a user checks a box it will send a value of true 
    and change the formbean value to true.  
    If the user does not check the box then the formbean value will remain false.  This will work reliably as long as the formbean 
    is new for each request.  
    To display the current value of the checkbox to the user put a c:if around the "checked" attribute.  
    
    Javascript relying on the current state of the checkbox should use the checked state of the box, not the value. 
    
-- struts 1 to struts 2 action mapping

    <action  path="/myMapping"
         type="com.myCompany.MyAction"
         name="articleForm"
         scope="request"
         roles="employee,admin">
       <forward name="success" path="/myPage.jsp"/>
     </action>
     
     <action name="myMapping" class="com.myCompany.MyAction">
        <interceptor-ref name="completeStack"/>
        <interceptor-ref name="roles">
            <param name="allowedRoles">employee,admin</param>
        </interceptor-ref> 
        <result name="success">/myPage.jsp</result>                 
    </action>