Spring framework

How the Spring 3.0 @Configuration Annotation Trounced the Monolithic Spring XML File

By Mark Spritzler

TheServerSide.com

Mark is a trainer and consultant for companies like SpringSource, NTier Training and JBoss. Mark is an expert in Spring, Hibernate and iPhone development. More importantly, he's also a Bartender at the JavaRanch.

Simplified Configuration with Spring and the @Configuration Annotation

For a few years there has been a Spring Module called Java Config that stood silently in the corner waiting for the right time to pounce. Well, Spring 3.0 is that right time. With the release of Spring 3.0, SpringSource has pulled this module into the core Spring Framework as @Configuration.


But what is @Configuration? Why should we use it when we have XML and annotations for configuration already? Why do we need yet a third way to configure our applications?
This is like trying to solve the XML versus annotation religious wars. (Don't even ask about curly braces.) The fact is, XML and Annotations both have very valid pros and cons.

 

Spring Configuration Options: XML vs. Annotations

The XML camp talks about separation of concerns. XML configuration is outside the classes. The whole configuration can be viewed easily in only a few files. Furthermore, configuration can change without recompiling, etc.

Cons of XML could be that we have all these String values that need to be converted. Typos occur all over the place, they are difficult to debug, and they are not type safe because of the Strings.

The Annotations party, like myself, like the type safety of annotations. It can also self document a class, so that you can look in the class and truly see what is being injected by Spring.

The cons of Annotations is that it clutters the POJO, sometimes where you might say it is not a POJO anymore. If you change, add or delete, annotations require a recompilation and deployment.

So, who wins the debate?

Guess what: they are all correct. There is no best answer to this debate. So wouldn't it be great if we could get the 'pro' benefits of both styles and remove the cons.
With @Configuration, we can do just that.

@Configuration is configuration using Java classes. Each @Configuration Java class is its own configuration. Since it is Java, it is type safe, we can keep it as a POJO (with just a couple of annotations, we promise not too much), and we can have a clean separation of concerns. We will also have a single resource representing the application's configuration, and we can change it without having to change our application code.

 

So how do we use @Configuration?

First we create a Java class and add one annotation to it @Configuration.
Then we create methods with code to instantiate the application's classes and call other methods to configure the dependencies.

We add one annotation to these methods. @Bean.

Here is an example of an @Configuration configuration class.

@Configuration
public class DataAccessConfiguration {

   @Bean
   public DataSource dataSource() {

     DataSource dataSource = new OracleDataSource();
     dataSource.setURL();
     dataSource.setUser();
     return dataSource;
 
   }

   @Bean
   public PlatformTransactionManager transactionManager() {
     PlatformTransactionManager transactionManager
                = new BasicDataSourceTransactionManager();
     transactionManager.setDataSource(dataSource());
     return transactionManager;
   }

}


In our example we are creating the infrastructure beans of a standalone application using JDBC. We have two methods: dataSource() and transactionManager(). Each are annotated with @Bean, which means the returned object in each method will be a Spring Bean added to the ApplicationContext. To handle dependencies, we have the transactionManager.setDataSource call the dataSource() method. That is all!

There are other annotations that you can add to your Configuration class that match almost everything that you can do in either XML or class annotations, including @Scope and @Primary. These configuration classes are easily tested because they are POJOs. Try writing a unit test with xml or annotations configurations.

It should be evident that in the @Configuration, that the code in the methods would have been the exact code you would have had to written in the first place if you were not using Spring. So you might ask, then why even use Spring? Well, we still need all the powerful goodness of Spring to manage our beans and their lifecycle, and to be able to add Spring enterprise abstractions through dynamic proxies. As well as Templates, Exporters and FactoryBeans that Spring provides. But those are other tutorials in themselves. For now, just enjoy the @Configuration.

 

 

***********************

 

Mark Spritzler is the owner of Perfect World Programming, LLC. Mark is a trainer and consultant for companies like SpringSource, NTier Training and JBoss. Mark is an expert in Spring, Hibernate and iPhone development. You can contact him through the "contact us" page at  perfectworldprogramming.com.

www.perfectworldprogramming.com
mediaserverblog.wordpress.com

Read Mark Spritzler's article on Spring Formatters and Converters
Read Mark Spritzler's article on Customizing the User Authorization Process through Spring Security

***********************

Books by Spring's Founder, Rod Johnson

 

05 May 2010

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.