NFJS - Day 3

Spring Talks by Keith Donald
Spring has largely been my focus for the last few years so I was happy to see one of the Spring Source crew stepping up at NFJS. Keith Donald is the lead of almost all Spring web related technologies and he tends to give a very down to earth, code centric presentation so I devoted all of my final day to his talks.

Someone in the audience asked Keith if he missed the common XML file that shows exactly how all your beans are wired when you move to annotation driven POJOs and that question is an important one. I've recently become much more comfortable with developing Spring applications due to the Spring Facet in IntelliJ. Moving to annotations tends to make me question exactly which resource or component is plumbed in to fill a dependency. Keith mentioned that an emerging best practice is to use annotations for self describing application dependencies, XML for infrastructure concerns. He also gave a soft sell for Spring IDE to show a nice dependency graph regardless of annotations or XML.

Spring 2.5 is downright giddy with it's extensive use of annotations and it didn't really dawn on me until Keith's talk that it might be the better way to go in some scenarios. I've traditionally balked a little bit at the extensive use of annotations as it feels very invasive to the code at hand, especially when the annotations are Spring specific. More importantly, swapping out facilities for testing purposes is not trivial when you are doing component scanning and autowiring with annotations. I think Keith articulates an appropriate scenario for use though. Swapping out mock classes via XML is not a benefit that is needed as much for application dependencies as it is one that is needed for infrastructure (data access, email service, file reader, etc...). Go nuts with annotations at the app level, but use a good editor and keep the XML where it belongs for infrastructure pieces.

Keith spent a good amount of time in all of his talks using an IDE focused on Spring MVC controllers. The thing that stood out to me was how Spring web controllers are truly just POJOWAs now (I know that's not a term that will stick but a distinction needs to be made between POJOs and POJOs with annotations). This means that you will rarely see HttpServletRequest or ModelAndView type classes in these POJOs. What's the benefit here? You don't have to waste many of your test cycles mocking up the container objects. Wanna test your login method on the controller? Send in a User object and a String password and then validate whether you are getting a success or error redirect back. Very simple, and anything that we can do to lower the barrier of entry to good testing is well worth it.

Keith demonstrated another key change in coding Spring apps is the impact that Rails has had on the Spring community. The focus has shifted in Spring 2.5 to more sensible defaults and a true convention over configuration model. Controllers in Spring web apps now mimic Rails controllers in URL and request parameter resolution. Additionally, there are a set of special parameter types that are automagically injected. An arg of type Principal will be supplied by the container if the user is already logged in. Very cool.

One final note on the Spring web side. Why do we have another javascript framework? If you have improvements to make to DOJO, please just contribute them to DOJO. Don't create an abstraction layer over DOJO that does what you need. We have finally whittled the .js framework comparison down to a handful in my mind (prototype/scriptaculous, dojo, jquery, yui, and ext). Don't lead us back in the other direction.

Conference conclusion
NFJS again provided some immediate exposure to worthy technologies and processes. I was able to touch base with a lot of people in the Java community that I hadn't seen in some time and I feel like I have more tools in my belt than when the conference started. A special note to the organizers though. If the prices go up again next year while the number of conferences goes up as well, then you won't see me there for the first time in 4 years. It was evident to me this year that the conference is not the value that it was 2 and 3 years ago. If the trend continues, I'd rather spend my training dollars on codemash, erubycon, and books.