How Spring Boot Auto‑Configuration Works: A Deep Dive into the Mechanics

This piece is part of a series of 1000 interview‑style articles, currently at entry 173, focusing on Spring Boot—a must‑know skill for both development and job interviews.

Spring Boot’s popularity stems from its "convention over configuration" approach, integrating most popular third‑party technologies and simplifying setup.

Spring Boot Configuration Files

Spring Boot uses a global configuration file, either application.properties or application.yml, where properties such as server.port and logging.level.* are defined. These properties are documented in the official Spring Boot reference.

https://docs.spring.io/spring-boot/docs/2.1.0.RELEASE/reference/htmlsingle/#common-application-properties

IDE assistance (e.g., IntelliJ IDEA, Eclipse YEdit) can also suggest available properties.

How do these configurations take effect in a Spring Boot project? The answer lies in the auto‑configuration mechanism.

Working Principle Analysis

The auto‑configuration source resides in the spring-boot-autoconfigure‑x.x.x.x.jar file.

The @SpringBootApplication annotation, present on the main class, includes @EnableAutoConfiguration, which triggers the auto‑configuration process.

@EnableAutoConfiguration

@EnableAutoConfiguration

is a meta‑annotation that uses @Import to import AutoConfigurationImportSelector. Its selectImports() method calls SpringFactoriesLoader.loadFactoryNames() to scan all JARs containing META-INF/spring.factories. The spring.factories file lists keys such as EnableAutoConfiguration with values that are comma‑separated auto‑configuration class names (e.g., xxxxAutoConfiguration).

During SpringApplication.run(...), the selectImports() method loads these auto‑configuration classes into the Spring container.

Auto‑Configuration Activation

Each XxxxAutoConfiguration class becomes active only when certain conditions are met, expressed via conditional annotations: @ConditionalOnBean: active if a specific bean exists. @ConditionalOnMissingBean: active if a specific bean is absent. @ConditionalOnClass: active if a class is present on the classpath. @ConditionalOnMissingClass: active if a class is absent. @ConditionalOnProperty: active based on a property’s value, e.g.,

@ConditionalOnProperty(prefix="xxx.xxx", name="enable", matchIfMissing=true)

.

For example, the ServletWebServerFactoryAutoConfiguration class binds the server.port property (default from org.apache.catalina.startup.Tomcat) via @EnableConfigurationProperties on ServerProperties. The @ConfigurationProperties annotation binds configuration file entries to the ServerProperties bean, which is then imported into the container.

Thus, any XxxxProperties class defines the set of configurable properties (prefixed accordingly), and the corresponding XxxxAutoConfiguration class registers beans based on those properties.

Spring Boot starts by using @EnableAutoConfiguration to locate all auto‑configuration classes listed in META‑INF/spring.factories, loading them as JavaConfig classes whose bean definitions are driven by @ConfigurationProperties‑bound property beans such as server.port.

Below is a diagram summarizing the flow (image sourced from Wang Fu‑qiang’s blog):

In summary, when reading the source code, focus on the overall mechanism rather than every implementation detail: XxxxProperties encapsulates configuration properties, while XxxxAutoConfiguration registers the corresponding beans.

Author: 圣斗士Morty Source: blog.csdn.net/u014745069/