Powered by Struts 2.x

After working with Struts 2.x for some months now, I feel more comfortable in commenting on some of the features that I feel have been helping me as well as some others that I feel needs some attention. In writing these, I hope that I may be able to learn some from those who may wish to attempt correcting me.

Overall Configuration

The basic file needed is one named "struts.xml". Properties (constants) can be overridden using a struts.properties files. This file takes priority and this is an interesting approach and this seems to mixed well with Maven environments (as well as Ant, of course). You can modularize your application including files of the same type (same DTD) as struts.xml. The one thing I don't understand is the use of DTD over XSD. Not exactly sure why they haven't adopted XSD as the latter are simply more powerful.

Rendering Engine

The fact that you don't need to JSP for your views has been a significant change for me. I know that you can avoid using JSPs using Struts 1.x but the amount of code (and configuration) could be very tedious. With Struts 2.x support for Velocity and Freemarker are already built-in. I've been using the latter for sometime now and I simply love it.

Now, if you consider the "hype" that OSGI is bringing to the JEE world, a templating engine technology (e.g. Velocity, Freemarker) over JSP technology is more appealing as this will allow OSGI environments to resolve proper templates based on the OSGI headers (within each jar). Struts 2.x comes with bundled with a set of predefined templates that the classloader picks from, thus encouraging this pattern (but not demanding it). I see this as a strategic architectural choice which ought to be observed when considering OSGI powered applications.

Servlet Technology and Controllers

Struts 2.x uses Servlet filters (instead of Servlets) as the driving force of the application. This can be good and bad for several reasons. I have found it to be good thus far. Filters can give you the feeling that "intercepting" a controller is simpler (filtering the request). Struts 2.x has default interceptors for different things such as those that parses the parameters and placed them into the value stack, double token submissions, etc. You can always implement your own.

You have a clear option of which interceptors to use and their ordering. This is a powerful feature that if misused can prove a big problem. I recently found a bug on the way I had configured our interceptors. You can do nesting of interceptors so I was repeating the same interceptor multiple times thus doubling my round-trips to the database. Implementing your own is very trivial.

Additionally, Struts 2.x advertise thread-safety POJOs as your actions (Struts 1.x should remember that this issue can make you rely heavily on request/session attributes). I have found that the nature of making this action objects thread-safe are by virtue of having a "request" scope. Since you have an option to use Spring for dependency injection, you configure/annotated your POJOs with scope "session" and block this behavior. I've found this a problem in some cases. I'm still investigating this issue, but does bring something to the table. You can effectively perform IoC in the way Action (controllers) are used as part of your MVC.

IDE Tooling - The good, the bad and the ugly!

As most fairly new frameworks tooling is what helps the adoption of a framework. Struts 2.x lacks this component very much as there are not that many IDEs with out-of-the-box support for Struts 2.x. As of the today, there are few who show some promise, none of which I would recommend investing (yet!). I am a fan of Eclipse, and I have to say that the WTP project works just fine with Struts 2.x and developing with it has been a breeze. Configuring struts 2.x within eclipse is somewhat trivial and I expect IDE plugins to simply help with XML editing.

I have spent a lot of time reading the struts-core source code and I simply like it. I think its a good practice for any developer trying to understand the framework and I'm sure you'll find it very readable, well commented with few problems (although I'm sure there are some). Overall, my experience with Struts 2.x has been very pleasant and I have good reasons to recommend it as a choice for development of new enterprise applications.