Order of Configuration in Spring Boot

1. Overview

In a Spring Boot application, multiple configuration classes often coexist to define beans, properties, or integrations. While Spring automatically detects and processes these configurations, it doesn’t guarantee the order in which they are handled. In scenarios where configurations depend on each other, or we need predictable initialization (for example, a data configuration before service configuration), controlling the order of configuration becomes crucial.

In this tutorial, we explore how Spring Boot determines the configuration order during application startup and how developers can control it using annotations such as @Order, @AutoConfigureOrder, @AutoConfigureAfter, and @AutoConfigureBefore. We also explain the difference between regular configuration and auto-configuration ordering, helping readers understand when and how each mechanism applies. To solidify these concepts, the article includes fully runnable examples along with unit tests that demonstrate the behavior of different ordering strategies in practice.

2. Understanding Configuration Classes

Spring configuration classes can appear in two forms: full and lite configuration. A full configuration class is annotated with @Configuration, whereas a lite configuration class is annotated with @Component, @Import, or contains at least one method annotated with @Bean. Both types are processed by Spring’s ConfigurationClassPostProcessor, which scans their annotations, interprets the metadata, and registers the corresponding bean definitions during the application startup phase.

3. Default Behavior of Configuration Ordering

By default, Spring Boot doesn’t guarantee any order for processing configuration classes. It scans all candidates and loads them as found in the classpath.

3.1. Example Without Explicit Order

The following code defines two independent configuration classes, ConfigA and ConfigB:

@Configuration
public class ConfigA {
    
    @Bean
    public String beanA() {
        return "Bean A";
    }
}

@Configuration
public class ConfigB {
    
    @Bean
    public String beanB() {
        return "Bean B";
    }
}

Here, both configurations declare beans that are unrelated to each other. When Spring loads these configurations, both beans are registered successfully, regardless of which configuration class is loaded first.

Before running the test, it’s essential to verify that both beans are present in the context, regardless of their load order:

@SpringBootTest
class DefaultConfigOrderUnitTest {

    @Autowired
    private ApplicationContext context;

    @Test
    void givenConfigsWithoutOrder_whenLoaded_thenBeansExistRegardlessOfOrder() {
        assertThat(context.getBean("beanA")).isEqualTo("Bean A");
        assertThat(context.getBean("beanB")).isEqualTo("Bean B");
    }
}

This test confirms that Spring registers both beans, even though no specific order is defined. The container doesn’t enforce or rely on any explicit sequencing.

3. Controlling Order Using @Order Annotation

Sometimes the initialization order matters, for example, when one configuration depends on beans from another. The @Order annotation helps enforce a predictable loading sequence.

Here, the ConfigOne class must load before the ConfigTwo class. We specify explicit order values:

@Configuration
@Order(1)
public class ConfigOne {

    @Bean
    public String configOneBean() {
        return "ConfigOneBean";
    }
}

@Configuration
@Order(2)
public class ConfigTwo {

    @Bean
    public String configTwoBean() {
        return "ConfigTwoBean";
    }
}

Spring processes ConfigOne before ConfigTwo since its order value is lower. While the order does not affect independent beans, it ensures dependency order when necessary.

The following unit test validates that both beans are created, and since ConfigOne has a smaller order value, it will load before ConfigTwo. However, bean creation order is not directly observable unless one configuration depends on another:

@SpringBootTest(classes = {ConfigTwo.class, ConfigOne.class})
class OrderedConfigUnitTest {

    @Autowired
    private ApplicationContext context;

    @Test
    void givenOrderedConfigs_whenLoaded_thenOrderIsRespected() {
        String beanOne = context.getBean("configOneBean", String.class);
        String beanTwo = context.getBean("configTwoBean", String.class);

        assertThat(beanOne).isEqualTo("ConfigOneBean");
        assertThat(beanTwo).isEqualTo("ConfigTwoBean");
    }
}

Even though the ConfigTwo class is declared first in the test class, Spring still loads ConfigOne first, respecting the order annotation.

4. Managing Dependencies Using @DependsOn

Sometimes a bean explicitly depends on another bean’s initialization. The @DependsOn annotation enforces this relationship at the bean level rather than the configuration level. Let’s see how one bean depends on another:

@Configuration
public class DependsConfig {

    @Bean
    public String firstBean() {
        return "FirstBean";
    }

    @Bean
    @DependsOn("firstBean")
    public String secondBean() {
        return "SecondBeanAfterFirst";
    }
}

Here, secondBean depends on firstBean. Spring ensures firstBean is fully initialized before creating secondBean.

The unit test below ensures both beans are registered and that the dependent bean is available after its dependency:

@SpringBootTest(classes = DependsConfig.class)
class DependsConfigUnitTest {

    @Autowired
    private ApplicationContext context;

    @Test
    void givenDependsOnBeans_whenLoaded_thenOrderIsMaintained() {
        String first = context.getBean("firstBean", String.class);
        String second = context.getBean("secondBean", String.class);

        assertThat(first).isEqualTo("FirstBean");
        assertThat(second).isEqualTo("SecondBeanAfterFirst");
    }
}

The test ensures both beans exist and are initialized in the correct order, as defined by the @DependsOn annotation.

5. Auto-Configuration Order in Spring Boot

Spring Boot uses auto-configuration classes to set up application defaults. When multiple auto-configurations exist, Spring determines their order using @AutoConfigureOrder, @AutoConfigureAfter, and@AutoConfigureBefore.

Let’s explore these further:

@Configuration
@AutoConfigureOrder(1)
public class FirstAutoConfig {

    @Bean
    public String autoBeanOne() {
        return "AutoBeanOne";
    }
}

@Configuration
@AutoConfigureAfter(FirstAutoConfig.class)
public class SecondAutoConfig {

    @Bean
    public String autoBeanTwo() {
        return "AutoBeanTwoAfterOne";
    }
}

SecondAutoConfig ensures it loads after FirstAutoConfig, using @AutoConfigureAfter. These annotations allow Spring Boot to manage configuration sequencing internally.

The test below confirms that beans from auto-configurations are present in the application context:

@SpringBootTest(classes = {SecondAutoConfig.class, FirstAutoConfig.class})
class AutoConfigOrderUnitTest {

    @Autowired
    private ApplicationContext context;

    @Test
    void givenAutoConfigs_whenLoaded_thenOrderFollowsAnnotations() {
        String beanOne = context.getBean("autoBeanOne", String.class);
        String beanTwo = context.getBean("autoBeanTwo", String.class);

        assertThat(beanOne).isEqualTo("AutoBeanOne");
        assertThat(beanTwo).isEqualTo("AutoBeanTwoAfterOne");
    }
}

Even though SecondAutoConfig is listed before FirstAutoConfig in the test, the annotation ordering ensures Spring still loads them in the correct order.

6. Conclusion

In this article, we discussed the order of configuration in Spring Boot as an essential tool for building predictable and maintainable applications. By combining @Order, @DependsOn, and auto-configuration annotations, developers can precisely control the startup sequence and avoid initialization conflicts.

These techniques ensure that our application context loads consistently, whether configurations are user-defined or auto-configured.

For most applications, explicit configuration ordering is unnecessary. Spring’s dependency resolution mechanism handles bean creation order automatically based on dependencies. Use configuration ordering judiciously, only when the sequence of configuration processing genuinely impacts our application’s behavior. As always, the code for these examples is available over on GitHub.