Spring Boot Auto-Configuration

No. Auto-configuration classes are ordinary Spring configuration classes with @Bean methods, the same kind you write yourself. The only difference is that they carry conditions, and Spring Boot loads them from a list inside its JARs instead of finding them by component scanning.

You can open any of them in your IDE. Search for a class such as JacksonAutoConfiguration and read exactly what it creates and under which conditions.

One of its conditions failed. The most common reasons:

• A dependency is missing, so @ConditionalOnClass fails.
• You defined a bean of the same type, so @ConditionalOnMissingBean makes Spring Boot step back.
• A property switched it off, or a required property is missing.
• It was excluded, on the annotation or in spring.autoconfigure.exclude.

Do not guess: run with --debug and search the Negative matches section of the report for the auto-configuration you expected. It names the exact condition that failed.

Only a little. Most conditions are cheap checks, such as “is this class present?”, and Spring Boot pre-filters candidates using metadata generated at build time, so most non-matching classes are skipped quickly.

The bigger cost is the beans that do get created. To keep startup fast:

• Remove starters and libraries you do not use.
• Exclude auto-configurations for features you do not need.
• For the fastest startup, use Spring’s ahead-of-time (AOT) processing and GraalVM native images.

In your application code, use @Configuration. Use @AutoConfiguration only when writing a reusable library that should configure itself.

If a component scan finds your auto-configuration class, Spring treats it as normal user configuration. It is then processed too early, before other auto-configurations, so:

• Conditions like @ConditionalOnBean may see the wrong set of beans.
• before and after ordering is ignored.
• Applications cannot exclude it with spring.autoconfigure.exclude in the usual way.

Put auto-configuration classes in their own package, for example com.example.audit.autoconfigure, outside the application’s scanned packages, and register them only through the .imports file.

@ConditionalOnBean only sees beans that have been registered so far. In ordinary @Configuration classes, the order in which classes are processed is not guaranteed, so the bean you check for might be registered a moment later. The condition then fails, even though the bean exists.

Inside auto-configuration it is reliable, because auto-configurations run after all user configuration and can declare their order with after = .... In application code, prefer @ConditionalOnProperty, or inject an ObjectProvider and check it at runtime:

@Bean
public ReportService reportService(ObjectProvider<EmailSender> emailSender) {
    return new ReportService(emailSender.getIfAvailable()); // null if no EmailSender bean
}

By what is on the classpath. The web starter includes Tomcat, so Tomcat’s auto-configuration matches. To switch, exclude Tomcat and add Jetty:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
    <exclusions>
        <exclusion>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-tomcat</artifactId>
        </exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jetty</artifactId>
</dependency>

No code changes are needed: @ConditionalOnClass now finds Jetty instead of Tomcat, and the matching server is configured.

It depends on whether you set a URL:

• No spring.datasource.url: Spring Boot starts an embedded database, H2 here, because it can run without any connection details.
• URL set to a MySQL address: Spring Boot connects to MySQL, and H2 is simply unused.

A common setup keeps H2 for tests and local experiments, and sets the MySQL URL in a profile:

# application-prod.properties
spring.datasource.url=jdbc:mysql://db.internal:3306/shop
spring.datasource.username=shop
spring.datasource.password=${DB_PASSWORD}

Yes: replace @SpringBootApplication with @Configuration and @ComponentScan, leaving out @EnableAutoConfiguration. You must then define every bean yourself, including the web server and the JSON converter.

This is rarely a good idea, because you lose most of what Spring Boot offers. A middle way is @ImportAutoConfiguration, which applies only the auto-configurations you list:

@Configuration
@ComponentScan
@ImportAutoConfiguration({
        JacksonAutoConfiguration.class,
        DataSourceAutoConfiguration.class
})
public class MinimalApplication { }

Slice tests are faster because they apply only a small, relevant set of auto-configurations. If a slice test needs one extra feature, add it with @ImportAutoConfiguration.

When Spring Security is on the classpath and you have not configured any users, its auto-configuration creates one default user named user, with a random password printed in the log:

Using generated security password: 3f1c2a9e-8b7d-4c55-9e21-6a0d7f4b2e18

This keeps a new application from being accidentally open. It disappears as soon as you define your own security setup, for example a UserDetailsService bean, or configure a login provider such as OAuth2. Never rely on this default user in production.

Through @ConfigurationProperties classes. Each auto-configuration has one, bound to a prefix, for example spring.datasource or server. Spring Boot fills it from your properties and environment variables, and the auto-configuration reads from it when creating beans.

Name matching is flexible. All of these set the same value:

server.max-http-request-header-size=16KB      (application.properties)
SERVER_MAXHTTPREQUESTHEADERSIZE=16KB         (environment variable)
--server.max-http-request-header-size=16KB    (command-line argument)

Library JARs also ship metadata describing every property, which is how your IDE can auto-complete names and show descriptions.

Older Spring Boot versions listed auto-configuration classes in META-INF/spring.factories. Spring Boot 2.7 introduced the dedicated AutoConfiguration.imports file, and Spring Boot 3.0 stopped reading auto-configurations from spring.factories.

If a library you upgraded silently stops configuring itself on Spring Boot 3, this is a likely cause. Move its entries into:

META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

spring.factories still exists for other purposes, such as registering listeners, but not for auto-configuration.

Names starting with spring-boot are reserved for official Spring Boot modules. For your own, put your project name first:

For small libraries, a single module containing both is fine. Separating them helps when users want the auto-configuration without all the starter’s optional dependencies.

@SpringBootApplication switches on both: component scanning for your code, and auto-configuration for everything else.

Yes. Many auto-configurations accept customizer beans. Spring Boot creates the bean as usual and then passes it through your customizer, so you keep all the defaults and change only one detail:

@Configuration
public class WebServerConfig {

    // Adjust the auto-configured web server instead of replacing it
    @Bean
    public WebServerFactoryCustomizer<ConfigurableServletWebServerFactory> serverCustomizer() {
        return factory -> factory.setPort(9090);
    }

    // Add to the auto-configured RestClient.Builder used across the app
    @Bean
    public RestClientCustomizer defaultHeaders() {
        return builder -> builder.defaultHeader("X-Client", "shop-service");
    }
}

Customizers are a good middle ground between setting a property and defining a whole bean yourself.

No. Auto-configuration depends on which libraries are present, not on the order they are listed in. Order between auto-configurations is controlled only by their before and after settings.

What does matter is which version of a library ends up on the classpath. Let Spring Boot manage versions, and avoid overriding them unless you have a specific reason.

Spring Boot ships well over a hundred auto-configuration classes, covering web servers, databases, messaging, caching, security, monitoring and more.

Only a fraction are applied in any given application. A simple web service might use a few dozen, because most conditions fail: no MongoDB driver means no MongoDB configuration, and so on. The --debug report shows the exact split for your application.

Spring Boot Actuator has endpoints that show what is configured in a running application:

management.endpoints.web.exposure.include=health,configprops,env,beans,conditions

These endpoints reveal internal details, so expose them only in development or behind security.

Yes, with one important difference. For native images, Spring’s ahead-of-time (AOT) processing evaluates the conditions at build time and generates plain code for the result.

This means the decisions are fixed when you build:

• The classpath cannot change at runtime.
• Conditions on properties are evaluated with the build-time values, so switching a feature on later with a property may not work as expected.
• Profiles that change which beans exist should be decided at build time too.

In return, the application starts in a fraction of the time, because no conditions are evaluated at startup.