Spring Java Configuration

Steve HansonApril 15th, 2013Last Updated: November 21st, 2022

5 119 3 minutes read

I have found that a lot of Spring developers I know still do not know about or use Spring Java Configuration (aka JavaConfig). Spring 3.0 introduced this feature which allows Spring to be configured entirely in Java – no more XML!! I really enjoy using JavaConfig because, well… it’s Java! This means it has all the benefits of Java type-safety and IDE support:

Typos generate compile-error – no more waiting till load time to find XML typos
IDE refactoring tools will automatically update JavaConfig because it is regular Java
IDE automatic import feature can be used instead of typing fully-qualified class names in XML
IDE drill-down feature
IDE auto-complete feature
I think you get it, anything that works with Java..

Some of the features above do come built into more advanced IDEs that have Spring support, but it is just nice to not rely on custom IDE Spring support to get these features. The compile-time checking is a big one for me. I refactor my code frequently, and changing field names or moving or renaming a Java file frequently breaks my XML Spring configuration. Of course, I usually don’t realize it until I deploy the application and get a Spring initialization error. Now, my IDE automatically updates the JavaConfig references when I refactor my code, because it’s just regular java. Also, if I forget to use my IDE’s refactor tools, I still get a compile error in the JavaConfig which alerts me before deployment that I have a problem.

Let me show a basic example of how XML configuration translates into JavaConfig. First, XML configuration:

<beans>
  <bean id="PersonService" class="com.codetutr.PersonService">
    <constructor-arg ref="personDao" />
  </bean>

  <bean id="personDao" class="com.codetutr.dao.PersonDao">
    <property name="endpoint" value="localhost" />
  </bean>
</beans>

Translated to JavaConfig:

package com.codetutr.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import com.codetutr.dao.PersonDao;
import com.codetutr.service.PersonService;

@Configuration
public class AppConfig {

    @Bean
    public PersonService personService() {
        return new PersonService(personDao());
    }

    @Bean
    public PersonDao personDao() {
        PersonDao personDao = new PersonDao();
        personDao.setEndpoint("localhost");
        return personDao;
    }

}

It is a pretty-simple one-to-one conversion. Each <beans> document is translated into a Java class annotated with @Configuration. Each <bean> element is translated into a single method annotated with @Bean. The name of the method corresponds to the bean ID. To reference another bean in JavaConfig, you just call the method for the desired bean (see personService above).

One other observation I have had about Spring JavaConfig is that it is more natural to use constructor injection over setter injection – because it results in a one-line method. This is a plus to me, as I usually prefer constructor injection. If a class requires certain dependencies to function properly, I prefer to require them in the constructor. That way, I can ensure that the class is initialized into a valid state. I have noticed that, for whatever reason, constructor injection seems to be rarely used in XML configuration. Maybe constructor-arg is too hard to remember? I don’t know, but I like that JavaConfig seems to be bringing that back some.

Now, to bootstrap the JavaConfig Application Context, Spring has provided a new ApplicationContext implementation: AnnotationConfigApplicationContext. It is used the same as we are used to using ClassPathXmlApplicationContext:

ApplicationContext ctx = new AnnotationConfigApplicationContext(AppConfig.class);
PersonService personService = ctx.getBean(PersonService.class);

Or if you’re in a web application:

<servlet>
    <servlet-name>myServlet</servlet-name>
    <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
    <init-param>
        <param-name>contextClass</param-name>
        <param-value>org.springframework.web.context.support.AnnotationConfigWebApplicationContext</param-value>
    </init-param>
    <init-param>
        <param-name>contextConfigLocation</param-name>
        <param-value>com.codetutr.config.AppConfig</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>

Note, that a package name or class-name can be passed in for the contextConfigLocation param above.

Or finally, if you’re using Servlet 3′s Java configuration:

public class SpringWebAppInitializer implements WebApplicationInitializer {
    @Override
    public void onStartup(final ServletContext servletContext) throws ServletException {
        final AnnotationConfigWebApplicationContext springContext = new AnnotationConfigWebApplicationContext();
        springContext.register(AppConfig.class);

        final ServletRegistration.Dynamic springServlet = servletContext.addServlet("myServlet", new DispatcherServlet(springContext));
        springServlet.setLoadOnStartup(1);
        springServlet.addMapping("/*");
    }
}

This post just scratched the surface of JavaConfig. I will follow-up with posts on how to import beans from other @Configuration classes or XML files as well as how to use custom namespaces. Also check out my post on how to set up a Spring-MVC application using JavaConfig.

Reference: Spring Java Configuration from our JCG partner Steve Hanson at the CodeTutr blog.

Spring Java Configuration

Thank you!

Steve Hanson

Thank you!

Thank you!

Related Articles

Thank you!