This is the first of a series of posts about setting up a RESTfull web application using Spring 3.1 with Java based configuration. The post will focus on bootstrapping the web application, discussing how to make the jump from XML to Java without having to completely migrate the entire XML configuration.

The Java based web configuration

@ImportResource( { "classpath*:/rest_config.xml" } )
@ComponentScan( basePackages = "",
   excludeFilters = { @Filter( Configuration.class ) } )
public class WebConfig{
   public PropertyPlaceholderConfigurer properties(){
      PropertyPlaceholderConfigurer ppc = new PropertyPlaceholderConfigurer();
      final Resource[] resources = new ClassPathResource[ ] {
         new ClassPathResource( "" ),
         new ClassPathResource( "" )
      ppc.setLocations( resources );
      ppc.setIgnoreUnresolvablePlaceholders( true );
      return ppc;

First, the @Configuration annotation - this is the main artifact used by the Java based Spring configuration; it is itself meta-annotated with @Component, which makes the annotated classes standard beans and as such, also candidates for component scanning. The main purpose of @Configuration classes is to be sources of bean definitions for the Spring IoC Container. For a more detailed description, see the official docs.

Then, @ImportResource is used to import the existing XML based Spring configuration. This may be configuration which is still being migrated from XML to Java, or simply legacy configuration that you wish to keep. Either way, importing it into the Container is essential for a successful migration, allowing small steps without to much risk. The equivalent XML annotation that is replaced is:

<import resource="classpath*:/rest_config.xml" />

Moving on to @ComponentScan - this configures the component scanning directive, effectively replacing the XML:

<context:component-scan base-package="" />

The configuration classes are filtered/excluded out of component scanning; this is because they are already specified to and used by the Container - allowing them to be rediscovered and introduced into the Spring context will result in the following error:

Caused by: org.springframework.context.annotation.ConflictingBeanDefinitionException: Annotation-specified bean name 'webConfig' for bean class [] conflicts with existing, non-compatible bean definition of same name and class []

And finally, using the @Bean annotation to configure the properties support - PropertyPlaceholderConfigurer is initialized in a @Bean annotated method, indicating it will produce a Spring bean managed by the Container. This new configuration has replaced the following XML:


Read the rest of the article at the following URL: 

Bootstraping a web application with Spring 3.1 and Java based Configuration, part 1