The introduction

Spring Boot has become a must-know skill at work and in job interviews. With the exception of some old government or financial projects that are on the fence, businesses are rapidly embracing the Spring startup framework, which is not so new.

Of course, as is the essence of Spring Boot, the process of auto-configuration is usually only useful in the “interview,” but it helps if you have a deep understanding of how Spring Boot works.

Spring Boot came into being thanks to the idea of “custom over configuration,” free of cumbersome configuration, difficult-to-integrate stuff (as most popular third-party technologies are), and based on the ability to conditionally configure beans provided by Spring 4.x.

Spring Boot configuration file

As we know from the beginning of Spring Boot, Spring Boot has a global configuration file: or application.yml.

All of our properties can be configured in this file. The most common ones are: server.port, logging.level.*, etc. However, only a few of them are actually used. The answer, of course, is yes. These properties can be found in the official documentation:

Docs. Spring. IO/spring – the boot…

(So, then again, looking for information must be official documents, Baidu out of a lot, or slightly amateur some)

In addition to the official documentation that provides a large number of attributes to explain, we can also use the IDE’s related hints, such as the IDEA auto-hint, and Eclipse’s YEdit plugin, can be very good for you to configure the properties, the following is the effect of using Eclipse’s YEdit plugin. The version of Eclipse is STS 4.

The above is a general overview of how to use the Spring Boot configuration file, but it’s actually an aside.

So here’s the question: how do these configurations work in a Spring Boot project? Next, it’s time to focus on the topic of this blog: how autoconfiguration works or how it is implemented.

Working principle analysis

The source code for Spring Boot is in spring-boot-autoconfigure-x.x.x.x.jar:

Of course, the description of the principle of automatic configuration, the official documents do not seem to mention. SpringBoot’s Boot class has a @SpringBootApplication annotation, which is an essential annotation for a SpringBoot project. Then the principle of auto-configuration must have something to do with this annotation!


@springbootapplication is a composite or derived annotation. In the @springbootapplication, there is an annotation @enableautoconfiguration, which translates to EnableAutoConfiguration. It is defined as follows:

This annotation is also a derived annotation where the key functionality is provided by @import, Its import AutoConfigurationImportSelector selectImports () method. Through SpringFactoriesLoader loadFactoryNames () scan all has the meta-inf/spring. The fac The Tories’ JAR. The spring-boot-autoconfigure-x.x.x.x.jar file contains such a spring.factories.

The spring.factories file is also a set of key=value, where one key is the full class name of the EnableAutoConfiguration class, and its value is a list of xxxxAutoConfiguration class names. These class names are separated by commas, as shown below:

The @enableAutoConfiguration annotation is indirectly marked on the SpringBoot Boot class via @SpringBootApplication. In SpringApplication. Run (…). The selectImports() method is executed internally to find the classes corresponding to the fully qualified names of all the JavaConfig autoconfiguration classes, and then all the autoconfiguration classes are loaded into the Spring container.

The article was first published in the public account of concern [Code ape technology column]

Automatic configuration Takes effect

Each XxxxAutoConfiguration class takes effect only under certain conditions. These conditions are reflected in Spring Boot in the form of annotations. The common conditional annotations are as follows:

  • @ConditionalOnBean: when the specified bean is in the container.
  • @ConditionalOnMissingBean: when the specified bean does not exist in the container.
  • @ConditionalOnClass: When the specified class exists in the classpath.
  • @ConditionalOnMissingClass: When the specified class does not exist in the classpath.
  • @ConditionalOnProperty: Whether the specified attribute has a specified value, for example@ ConditionalOnProperties (prefix = "XXX, XXX," value = "enable", matchIfMissing = true), which means the Boolean value of the condition is true when is enable and true if it is not set.

ServletWebServerFactoryAutoConfiguration configuration class, for example, to explain in the global configuration file attributes to take effect, such as: Server port = 8081, how work (of course not configuration will also have a default value, the default values from the org. Apache. Catalina. Startup. Tomcat).

In ServletWebServerFactoryAutoConfiguration class, there is a @ EnableConfigurationProperties comments: Turn on configuration properties, which is followed by a ServerProperties class, and this is where custom trumps configuration ends up.

On this class, we see a very familiar annotation: @ ConfigurationProperties, its role is binding properties from the configuration file to the corresponding bean, while @ EnableConfigurationProperties responsible for import this already binding properties of bean in the spring container (see screenshot above). All other properties associated with this class can then be defined in the global configuration file. That is, the classes that really “limit” which properties we can configure in the global configuration file are these XxxxProperties classes, which uniquely correspond to the set of properties beginning with the prefix keyword defined in the configuration file.

So far, we have a general idea. Globally configured properties such as: Server. port, etc. are bound to the corresponding XxxxProperties configuration entity class and encapsulated as a bean via the @ConfigurationProperties annotation. Then through @ EnableConfigurationProperties annotations into the Spring container.

Many XxxxAutoConfiguration classes, in the JavaConfig form of the Spring container, are used to import beans to the Spring container, and all the properties required by the imported beans are obtained through the xxxxProperties bean.

You may still have doubts so far, but when you interview, you don’t need to be so specific. You just need to say:

When Spring Boot starts, it finds all the autoconfiguration classes in the meta-INF /spring.factories configuration file using the @enableAutoConfiguration annotation and loads them. These AutoConfiguration classes are named after AutoConfiguration, which is actually a JavaConfig form of the Spring container configuration class. It can obtain the Properties configured in the global configuration file by using a class named after Properties: Server.port, and the XxxxProperties class is bound to the corresponding property in the global configuration file via the @ConfigurationProperties annotation.

To understand this complicated process, look at an icon:

Images from Wang Fuqiang teacher’s blog:


In summary, the principle of automatic configuration is explained. Of course, when browsing the source code, it’s important to remember not to get too bogged down in the implementation of the code, but to focus on the main points.

Remember that the XxxxProperties class encapsulates the relevant properties in the configuration file; XxxxAutoConfiguration class means: auto-configuration class, the purpose is to add components to the container.

The other main method starts to load the various XxxxAutoConfiguration classes.