There is a controller class that I’ll now call FooController. This was a Spring Controller that is used for several controller beans that could be called foo, fooBar and fooBaz:

  <bean name="foo" class="com.foo.web.FooController.class"/>
  <bean name="fooBar" class="com.foo.web.FooController.class"/>
  <bean name="fooBaz" class="com.foo.web.FooController.class"/>

Now for one of the beans, foo, we needed some other functionality, that we injected to the bean:

  <bean name="foo" class="com.foo.web.FooController.class">
    <property name="baz"><value><ref bean="theBaz"/></value></property>
  </bean>
  <bean name="fooBar" class="com.foo.web.FooController.class"/>
  <bean name="fooBaz" class="com.foo.web.FooController.class"/>

And we made changes accordingly to the FooController class, for the case that was needed in foo.

Then we started getting NullPointerExceptions from fooBar and fooBaz when they were executing the code of FooController that required baz, even though the views of fooBar and fooBaz did not need it.

So, even though Spring beans are by default singletons in the Spring sense, the Spring singleton sense is rather like Uncle Bob Martin’s Just Create One. Different beans having “singleton” instances of the same class will have their own instances, so providing the dependencies to the foo instance does not help the other instances.

Noticing this kind of errors earlier in the development is the reason why I prefer initialising the crucial dependencies of an object in the constructor, preferably making them final members. This way you cannot create an instance in a crippled state in the first place. Speaking fancy, this would be the “type 3” or constructor-based dependency injection. And for more complex dependencies I like context IoC as well.

Anyway, for a little simple problem like ours, we wanted to have a quick, simple solution. Here is the list of solutions we came up with. If you have more ideas I would be thrilled to hear them!

  1. Separate (sub)classes for each controller. Some day they will surely grow separate, but at this moment I felt awkward about littering the class space because of what is basically a configuration or dependency wiring issue.
  2. Making FooController a traditional singleton by putting factory-method="getInstance" to always return the same, statically held instance of the class and making the default constructor private. But this would have been both verbose in the Spring configuration XML and again littered our java code because of a wiring issue.
  3. Adding the dependecy wiring to each controller bean entry in the Spring XML. But this would have caused duplication in the XML.
  4. Making foo the parent bean of fooBar and fooBaz.

For now, we settled for the last solution that seems OK to me. Sometimes I have thought that the parent-child-hierarchy in the Spring configuration XML might make it too complicated, but in this case it feels justified and the configuration keeps looking fairly simple.

  <bean name="foo" class="com.foo.web.FooController.class">
    <property name="baz"><value><ref bean="theBaz"/></value></property>
  </bean>
  <bean name="fooBar" class="com.foo.web.FooController.class" parent="foo"/>
  <bean name="fooBaz" class="com.foo.web.FooController.class" parent="foo"/>
Advertisement