A Spring Module called Java Config has been there for some time now. With the release of Spring 3.0 SpringSource has pulled this module into the core Spring Framework as @Configuration.
How can we use this @Configuration in our application? and should we use it when we have XML and annotations for configuration already?
In Spring 2.5 we find that there is a support for Property Externalization. Which was good in several ways than before. What it meant was, that the properties file could be modified for different build environments by the administrator.
One good thing about this approach is that the administrator need not edit the application context file. Editing verbose XML has plenty of room for errors. Editing the properties file on the other hand is a whole lot simpler and is less error prone.
For example for configuring the datasource this is what we do typically. We used Property externalization in Spring 2.5 using PropertyPlaceHolderConfigurer.
What it does is that at the Configuration time right after the Spring has loaded the bean definitions it replaces these placeholders with the values defined in the externalized properties file. That means that whatever the values specified for driver class name, url, user name and password will now be set on the datasource bean for the application.
Important point to note here is that it is done at the configuration time. So, it is only done once while the application context file loads up.
This approach does have some drawbacks though:
- It only supports properties
- Replacement is done at initialization time not at bean creation time
- It does not support conditionals or other constructs
- It is not Typesafe
Let’s have a look how can we use a java based Spring configuration.
First we create a Java class and add @Configuration annotation to it. Then we define methods to instantiate the application’s classes and call other methods to configure the dependencies. We also add @Bean annotation to these methods.
For example If we have a bean name MyBean then we can create a Configuration annotated class like this
This is equivalent to the following bean definition in standard xml based spring configuration.
Both declarations make a bean called anyService available in the ApplicationContext bound to an object instance of type AnyServiceImpl.
If one bean depended on another bean then defining is as simple as having one bean call the other.
It is very easy to take sides here but both the Java based configuration as well as XML based has its own benefits. On one hand XML is declarative, Java is Object Oriented. Most will swear by advantage of one over other. I think both ways provide different semantics of doing the same thing and both approaches to configuration is ok if it suits application needs.