A little bit more DWR and Spring MVC

I've blogged before about integrating Spring and DWR. This is just an update (though interesting) with some clarifications due to a request in the DWR mailing list.

Each new version of the Spring framework adds flexibility mainly by adding new features. This, in turn, can mean added complexity even though the additions are well thought and easy to apply. The complexity comes with the mix and match. In some way, it's like Java itself, it's not the added complexity of a new language feature, it's the integration with the rest of the language and the corner cases that appear. This is commonly a consequence of backward compatibility and the absence of deprecation.

Spring MVC 2.x has included new implementations of the classical Controller interface. Along with them new view resolvers and mappings were developed. These new controllers provide a new way of getting things done, for example, using annotations, but were designed to work side by side with the rest of the framework. This can lead to some confusion, easily, when some controllers are instantiated using component scan, others are declared in XML, some are mapped by annotations, others using convention over configuration and the views are injected or resolved by name and/or URL. Add DWR to the mix and things get scary for the less experienced developers.

I will start with an advice, do not mix different technologies if at all possible. This will force you to choose a path and commit to it but it will pay benefits in the long run. Less is more.

So what options are available? I will list the ones I consider the more intuitive. There are more combinations possible and even more options that I won't list (for example, declare the URL as the bean id).

1. Use XML to explicitly declare beans and mappings
   As always have been made. It's simple and expressive. Views can be handled by a InternalResourceViewResolver. The schema is highly integrated so DWR just becomes a couple of added lines in the related beans. The bad news, the unneeded boilerplate.
2. Convention over configuration
   Use ControllerClassNameHandlerMapping and DefaultRequestToViewNameTranslator. Declare your beans in XML. Add a specific mapper for DWR at the end of the chain (order = 2).
3. Annotations all the way
   They're concise and powerful because they're attached to the element. Do not mix with XML or get ready for the mandatory pandemonium that you have started. By the way, HandlerMappings are usually easier than HandlerAdapters. Unfortunately, currently DWR annotations are not tightly integrated (something to improve) so you need to fall back to the provided schema which seems counterintuitive.

And that's pretty much it. As I know that some people will still reject the advice and throw everything together, I have prepared a little sample project. It features four different controllers, three different mappings and a couple of view resolvers in addition to a DWR remoted bean. It's available here. Hope it helps.