Migrating from WebWork to Stripes, Pt 1

The first in a series of blogs about converting an application from WebWork to Stripes.

To begin with..we arent officially moving our architecture to Stripes..at least not yet. Our site just went live in September, so switching a framework at this stage would probably cause folks to hunt me down :)

However, when i first proposed the webwork/spring/ibatis architecture way back in early December 2005, Stripes, while attractive, was only 3 or so months old. It was still too new for me to really consider basing a new site on. Plus, WebWork looked nice, and with the Struts merger announcement, i knew webwork/struts would be around for awhile.

Fast forward to today, and Stripes is up to version 1.41 and Struts 2 is finally in early release (not sure Struts 2.0 has had an official GA release yet). I've been looking at Stripes again for around a month now...and i keep reading stories about how slow OGNL is, and I am wondering if the lower than expected load capacity on one of the heavy pages on our site is due to OGNL. (more on that in a follow up post...though to be honest, the current version is fast enough for our needs in the near future. After working on weather.com and dealing with 60 million hits per day sometimes, i get rather picky on max requests per second). So, i thought i would try rewriting that heavy page in Stripes to see how it felt to develop in Stripes compared to Webwork.

First off, Stripes was VERY easy to get up and running. There was only one (one!) jar i needed to download (i already had commons-logging). I added a few lines to my web.xml and within 5 minutes had a Stripes demo page working. Nice.

Second, thanks to Spring, i DID NOT have to touch any of the model or DAO classes. although somewhat controversial, i like to use autowire by name in my spring classes to cut down on the size of my Spring xml file. I use the full class name DAO as variable names in my actions, and in my Spring file. For instance PersonDAO would be named personDAO in my actions and in my Spring file. That also happens to follow the naming convention in Eclipse if you let it autocomplete the field declaration for you. I like that i can add a new DAO to an action by just adding the field and not needing to modify the Spring file. For the few actions that can write to the db, though i do usually disable autowire by name.

So, since i didnt need to touch the other layers of the application..converting my webwork action to a Stripes action was almost ridiculously easy (it only involved changing the action itself, and the jsp for that action):

1) My action class now implements ActionBean, instead of extending ActionSupport
2) Added the url the action responds to via the @UrlBinding annotation (instead of declaring it in xwork.xml).
3) Changed my execute method from public String execute() to public Resolution execute() (though execute is not needed by Stripes..any method name would do..just has to be public and return a Resolution, i believe)
4) To hook my DAOs to Spring, add @SpringBean before each Spring injected bean (which is better than having this in the xwork.xml..as the Stripes annotation makes it more obvious that Spring is involved for documentation purposes. Yeah, it ties that action to Spring explicity, but since its just a one word annotation..its worth it for the self-documenting nature of the annotation)
5) the execute method now returns the jsp view as a String, instead of returning SUCCESS, and having SUCCESS for the action mapped to a jsp in the xwork.xml file

Unless i am forgetting something..thats all i did to convert an action from webwork to stripes. Nothing to it. And I LOVE how the annotations are also like documentation.

The final (and biggest piece) of the conversion is the jsp itself. I had relied entirely on the webwork tags for logic and action binding (which probably meant a lot of OGNL along with some freemarker). I didnt use JSTL or the EL at all. So, i had to come up to speed with JSTL and some of the limitations of JSTL and the EL. Webwork was a bit friendlier in this way. I liked that WebWork allowed be to easily call methods on the action that a jsp was mapped to. It took me awhile to figure out that i need to convert those types of methods to static so that i could create a custom tag file to access those methods via JSTL. In the long run, i think i'm better off with the standard JSTL in my pages, and only using a frameworks custom tags when they really save a lot of work. (though i dont think webwork plays well with JSTL, though i could be wrong).

I'm still learning JSTL as i convert, and think i almost have the page converted. The next step later this week (i hope) will be to load test this page to compare the results to the same page in webwork. That test will probably run in our test environment..so the raw numbers wont be very important..be the comparison of the numbers in each framework will be. I'll blog about those results when i get them..again, hopefully later in the week sometime.

Overall, I really, really like how easy and quick it is to develop with Stripes. The biggest drawback has been the limitations of JSTL. I wonder if Stripes has a tag that would allow me to call methods on beans or actions without having to resort to custom tags. Guess i should ask that question on the Stripes list. Down the road, i also want to try out Hibernate 3.2 and see how an all-annotations based architecture feels. But first i need to get a better handle on Stripes.