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.
- Home
- Converting Struts 1 to Struts 2
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.