I’ve always been a big fan of Picocontainer because it has a lovely programmatic interface as an IoC container, and I generally value programmatic APIs over external representations, particularly for config files (note that it doesn’t mean external representations aren’t useful).
Unfortunately the followers of Spring love writing their code in XML, and many of their examples don’t show what you need to do to wire up all their examples declaratively in code. I spent some time trying to work out how to do some things.
Bean with an id ‘myBean’
<bean id="myBean" class="com.thekua.example.SomeClass">in code:
GenericBeanDefinition someClassDefinition = BeanDefinitionBuilder.rootBeanDefinition(SomeClass.class).getBeanDefinition(); getDefaultListableBeanFactory().register("myBean", someClassDefinition);Guided by this article: Programmatically Build A Spring Application Context
I’ll add more examples for the more complicated items later.
If you want a really declarative approach you might want to look at the stereotype annotations, your example would look like this:
@Component
public class SomeClass {
}
And just a single line of XML, no matter how many beans you have:
I’ve heard people worry about coupling components to the Spring framework this way, because you use their annotation, but that’s not necessary either; you can create your own annotations, maybe describing the role of the component in more detail for other purposes.
The blog ate my XML… Let’s try this again. Here’s the line of XML needed:
<context:component-scan base-package=”org.example”/>
Hi Erik,
Thanks for that. I think we’d definitely consider using annotations, and is a much more succinct way of doing it declaratively.
Or…
SomeClass myBean = new SomeClass();
I like Nat’s approach. If the object has no dependencies why would you want it to be instantiated in some funky container. To be JEE compliant?
In general, I would also agree with Nat’s sentiments about simply creating new instances. However pragmatically, you are often bound by existing systems and constraints. In our such case, our system already depends on quite a lot of things registered via Spring (XML). The programmatic approach lets us evolve to a better solution in smaller steps.
Patrick, can you give an example of why the “programmatic” approach would lead you to a better solution in smaller steps? If you stick to code with annotations, all you get by writing the constructor calls is extra work, or am I missing something?
Also, if you write the constructor calls yourself you can’t benefit from the simple AOP model that Spring offers, and you also have to deal with handling the scope of your objects manually.
Hi Erik,
Part of the “programmatic” approach is about understanding alternatives. It’s not one that is documented very well. As I mentioned in a previous comment, we have a lot of things in our Spring XML, and there were some lifecycle events that, even with annotations wouldn’t have let us do what we want before Spring. To be honest, for many other cases, I’d agree with you in approach. For our specific case, I don’t think we would have achieved what we wanted without it. For some of our more “integration” tests, we used the same spring config, but deployed a different implementation for tests.
For example, we deployed a ControlledClock instead of a
SystemClockto give us a more controlled environment. An option we could have gone down, was load the objects we wanted, replace the objects we wanted to control, and then reinitialise the Spring context. We didn’t want to go down this path because we wanted to effectively, “assemble a bomb” to only “disassemble and reassemble it”. This “programmatic” approach gave us a more dynamic ability to assemble the right thing for our target environment without having to change annotation values or anything like that.