With a recent release of Crowd, our team decided to upgrade the WebWork 1.4 stack to version 2.2.4 which as of now is the most recent release.
When we originally sat down to write Crowd (previously IDX), we evaluated a variety of technologies and ended up picking version 1.4 because of the stability offered by the framework having a know list of limitations and bugs. Often it amazes me when a project (mostly inexperienced developers) uses the latest and greatest technology. Having a mature and proven technology increases your chances of success by limiting risk.
Now that version 2.x has been out for quite some time, we are able to take advantage of lessons learned from a variety of people who have already embarked on this challenge.
The first concern that we had is that all of JSP tag syntax would blow up. This turned out not to be as bad as expected, but did require every page to be updated in some capacity. Some of the value stack objects did not work out-of-the-box and tag libraries syntax was fully backwards compatible. Once we identified the core challenges in upgrading pages, one of our developers spear headed the task… after the first few pages he was able to move pretty quickly and was typing faster than I could follow when we did an analysis of a page update.
In parallel with the JSPs needing to be updated there are the servlet actions. Most of the actions themselves were coded well enough that almost no changes were necessary to these objects but the actions.xml configuration file needed to be converted over to xwork.xml. An XSLT/XML option exist for auto converting the actions over, but in the end you get a text file where you have no idea what is going on and may have potential mistakes.
We decided the best method would be to code out this file by hand and then test the various work flows because we needed to assure all output paths of the actions gave us the results we were looking for when testing. One thing I really like about the syntax of the new configuration file is the ability to specify namespaces where actions are permitted to run. This way users can not call your actions from URLs which you have no control over. This is great because it gives you granular security for URL paths.
Of course not everything went well, in fact at the end when we went to do our build outside of IDEA we ran into a nasty bug where our actions were not returning the view result even though a “SUCCESS

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now