We're back!

Geekyninja is back, after a long hiatus! I'll be blogging both here and at Critical Phase. Check out my new entry regarding Spring MVC 2.5 and all that annotated controller goodness: Fun with Spring MVC 2.5 Annotations.

SpringOne 2008

I missed The Spring Experience 2007, but was able to return in 2008, and it has been renamed to springOne. During Adrian Colyer's keynote, he posted this hilarious photo:
Yes, that's the Rod Johnson bobblehead doll! I'm so jealous of everyone who was able to attend in 2007. Hopefully they give out something like this in 2009.

On a more serious note, some of the highlights of the conference:

Managing the war on complexity: This was the theme of Rod Johnson's keynote, and I'm glad he explicitly said this, as Spring is truly one of the best solutions to making Java EE web apps simple to maintain and develop.

OSGi: Becoming very popular, and something worth looking into.

Spring MVC: The old Controller hierarchy is going away, and moving towards the annotation based Controllers found in 2.5. Also, Spring 3.0 will have native REST support!

Grails: If you follow the Grails scene, then you know that G2One, the company behind Grails, has been acquired by SpringOne. Rod just reiterated this to let the community know that Grails will have even better Spring support now that they are the same company.

Grails Eclipse plugin

So I was messing around with Grails the other day, and heard about the wonderful Eclipse plugin. Like the documentation says, grails generates all the necessary files for Eclipse to recognize your project.

This is great and all, but a lot of people I spoke to encountered the same problem I did.
There's a file for your Spring DSL code, called resources.groovy located in
<your-app>/grails-app/conf/spring.

Many people will then receive the following error:

Invalid Package declaration in script: <path-to-your-project>/grails-app/conf/spring/resources.groovy is not in a source folder matching the package declaration: DonutStore/grails-app/conf/spring resources.groovy


I don't know enough Grails at the moment, but a quick fix is to add:

package spring;

to the top of the file.

Update:I've been coding Grails apps for several months now, and realize that this is just an error with the Eclipse plugin. Since I develop on the Mac, I prefer TextMate anyway. However, if you're an Eclipse fan, be glad that the SpringSource guys are working on a new and improved plugin and it should be available later this year.

Spring method injection

I recently inherited some legacy code and it's been extremely difficult to refactor. It's a catch-22: you can't refactor without unit tests in place, but it's difficult to unit test since it wasn't written to be testable. [TDD can cure this. :)]

So after much hair-pulling and thought, I was able to extract a few interfaces and configure some of the business logic classes as Spring managed beans. The problem was that some of the dependencies were still being acquired via the "new" keyword, and it had to remain that way.

In other words, I had a singleton bean which required a non-singleton, or prototype. Not just once, at bean creation time, but a new instance every time. How could this be done, without mucking up my code with the Spring API? We definitely do not want a reference to a BeanFactory or ApplicationContext in our bean.

Enter one of the rarer forms of dependency injection: Method Injection (see section 3.3.8).

The recipe is:

1. Create a method for the dependency and either make it protected abstract, or public.
   
2. In your applicationContext.xml, instead of specifying <property name="someProperty">, you use
   <lookup-method name="theMethodWhichReturnsYourPrototype" bean="idOfPrototypeBean"/>
   

Let's look at an example:

We have a class Homer, which wants a new instance of another bean, a Donut, every time, instead of reusing the same Donut over and over again.


Now, for the applicationContext.xml:



<!-- a stateful bean deployed as a prototype (non-singleton) -->
<bean id="donut" class="demo.DonutImpl" scope="prototype">
<!-- inject dependencies here as required -->
</bean>

<!-- homer (singleton) uses donut (prototype) -->
<bean id="homer" class="demo.Homer">
<lookup-method name="getDonut" bean="donut"/>
</bean>

So what's going on here? To quote the Spring docs:

The Spring Framework implements this method injection by dynamically generating a subclass overriding the method, using bytecode generation via the CGLIB library.

So when Homer asks for a donut via getDonut(), the subclassed Homer, generated via CGLIB, will return a new instance of Donut, which has its dependencies injected by Spring.

Pros of this approach: we are decoupled from BeanFactory and the Spring API
Cons: making the bean abstract makes testing a little difficult, since you have to subclass the class, however, making it concrete and implementing the getter method, you avoid this.

SimpleFormController: onSubmit() not being called

I had a SimpleFormController and a validator. According to my logs, the command object passed validation, but I was not seeing the success-view. Upon closer inspection of the errors object in my validate method, I noticed Spring was having a problem converting the String (from the form input) to the Long property of my command class.
The solution is easy -- implement initBinder() in the controller and register a PropertyEditor.

XDoclet (EJB) and Spring

My project was using XDoclet to annotate our EJBs. I wanted to use Spring, and still keep the EJB, so I had the bean class extend Spring's AbstractStatelessSessionBean. The problem? The classes that XDoclet generated extended AbstractStatelessSessionRemote, AbstractStatelessSessionLocal, etc., all of which, don't exist.

The solution? Quite simple... by using the @ejb.home and @ejb.interface attributes, you can override the default behavior and specify which interface(s) the home interface and component interface should extend.

Example:
@ejb.home
extends="javax.ejb.EJBHome"
local-extends="javax.ejb.EJBLocalHome"