Summarize the springboot notes I have learned recently
yaml syntax
#对象
student:
name: juzi
age: 666
#行内写法
kid: {
name: jujuju,age: 888}
#数组
chars:
- naruto
- sasuke
- itachi
names: [zhangsan, lisi, wangwu]
Spring's el expression is also supported in yaml
@ConfigurationProperties
@ConfigurationProperties is specific to SpringBoot and has the following support:
- Support yaml and xml
- Support loose syntax, that is, the correspondence of various cases
- Support jsr303 data verification, add @Validation annotation
Unlike Spring's @PropertySource, it can only support xml (supporting others requires additional configuration)
path variable
- classpath:
Search in the current .class file path, the default is to search from the nearest classpath.
- file:
Use absolute paths. This is not recommended, as it couples the application configuration to the specific absolute path.
Principle of automatic configuration
Talk about your own understanding, not necessarily correct, but just a summary of existing knowledge.
Springboot has a main startup class as soon as it comes. When you click on the annotation, you will find that there is an EnableAutoConfiguration annotation. From the name, you can probably know that this is a class that enables automatic configuration, because it will inject various automatic configurations into it through the Import annotation. in the container .
SpringBoot的一大特色就是自动配置。见官网Starters条目下的解释：
Starters are a set of convenient dependency descriptors that you can include in your application. You get a one-stop shop for all the Spring and related technologies that you need without having to hunt through sample code and copy-paste loads of dependency descriptors. For example, if you want to get started using Spring and JPA for database access, include the spring-boot-starter-data-jpa dependency in your project.
Then, click on this annotation to find that the Import annotation is used. This is the usage of the ImportSelector interface. This interface mainly returns the class that needs to be a bean according to the situation. Enter the implementation method selectImports of this interface :
The return value of this method is a collection of the names of the classes that need to be imported. From the above, we can know that this collection is obtained by the method getAutoConfigurationEntry surrounded by the red box, and then continue to enter this method:
In this method, we will find that ImportCandidates.load is called , and configurations::add is performed on each element here , and then the configurations are returned to obtain all configuration classes.
Enter the ImportCandidates.load method and finally find that it will scan the META-INF/spring.factories file under the spring-boot-autoconfigure package . This file includes all automatic configuration classes, but of course not all of them will be used. Just click into a class and you will find that this class is also decorated with Configuration annotations, indicating that this is a container that transports beans. In addition, there is an annotation of EnableConfigurationProperties , the class corresponding to the value of the annotation is marked with the ConfigurationProperties annotation, the function is to let these classes be injected into the container, otherwise the ConfigurationProperties annotation will not take effect. Click on the setting to open the class of ConfigurationProperties , and you can find that it is read from the default application.properties file, so as to achieve the effect of customization. You can see that there are default value settings under this class. In addition, considering that not all springboot projects need to introduce all dependencies, some annotations that control the conditions for configuration can be found in these files that identify the automatic configuration class.
This method will not be used after springboot3.0, but will be placed in META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports .
I think the key to understanding the above is to understand Spring's IOC well, especially in various ways. You can see that springboot is not configured in the way of beans.xml, but is configured in the way of Java code, which involves many annotations. It is difficult to understand the operating principle of springboot without understanding it.
See what has been automatically configured
Configure debug=true in application.properties , then start the project, check the cmd window, the ones under positive matches are effective, and the ones under negative matches are not effective.
The difference between @Configuration and @AutoConfiguration
Literally, these two annotations are about configuration, that is, adding related beans to the container, so what is the difference between them? I think there are mainly the following differences:
1. Start up
In terms of the method , since ComponentScan is automatically added to the main startup class of springboot , all classes with Configuration annotations under the same package as the main startup class will be scanned. If you want the AutoConfiguration annotation to take effect, you not only need to add relevant annotations to the class, but also need to declare it in the spring.factories file (it can be in the META-INF folder under your own customized jar , or it can be spring-boot-autoconfigure The META-INF folder under this jar package ), so as to inform springboot to achieve the effect of automatic assembly (as mentioned above, the EnableConfigurationProperties annotation is to go here to find the corresponding class loading).
In terms of timing , by default, the class annotated by Configuration is started first, and then the class annotated by AutoConfiguration is started. I think this is also because the automatic configuration classes are all default configurations, which may be affected by their own custom configuration classes, so this order is adopted .
2. In terms of use
In fact, it can be seen from the above description that the positioning of the two is different. Configuration annotations are mainly for programmers to define some beans themselves, while AutoConfiguration annotations are more for collaborating with the springboot framework, which is why the AutoConfiguration annotation is proprietary to the springboot framework, not defined in the spring framework. Springboot focuses on automatic configuration . With this annotation, third-party libraries can better cooperate with the springboot framework. Therefore, AutoConfiguration annotations have many additional functions, such as before , after and other attributes to control the loading order, and are often used together with @ConditionalOnBean, @ConditionalOnMissingBean, etc.
Refer the following two links: What is the difference between @Configuration and @AutoConfiguration? , Should I choose Configuration or AutoConfiguration?
3. proxyBeanMethods attribute
Let's first understand proxyBeanMethods . This attribute mainly determines whether the method identified by the Bean annotation in the configuration class under the Configuration annotation returns a singleton, that is, whether multiple calls return a reference to the same object.
This article explains well what the proxyBeanMethods attribute does:
Detailed explanation of the proxyBeanMethods attribute in @Configuration
Spring is mainly implemented through Cglib dynamic proxy. Each call to this method only returns the same value, so there are many constraints, such as this method cannot be final , and it will also reduce performance, mainly in source code comments:
After understanding the proxyBeanMethods attribute, let's talk about the difference between the two annotations in this attribute. The attribute of the Configuration annotation is true by default, and the attribute of the AutoConfiguration annotation is false by default . Some libraries use a lot of Configuration annotations, and this is not a small performance expense. In order not to destroy backward compatibility, Spring Boot officials cannot directly change the attribute of the Configuration annotation to false, so they have to set it in AutoConfiguration is true.
The AutoConfiguration annotation is actually annotated with a Configuration annotation with a set value of false.
This answer does a good job of explaining the difference between the two annotations at this point:
When should the proxyBeanMethods of @Configuration be set to false
The difference between @ComponentScan and @AutoConfigurePackage
The same as the above two comments, here ComponentScan is a comment in spring, which is used to tell spring which components under the package need to be scanned, and AutoConfigurePackage is a springboot-specific comment. The package of the annotated class will be scanned. Its main purpose It cooperates with the get method of the AutoConfigurePackages tool class , so that third-party components can obtain the location of the main startup class package, and scan the resource files or classes in it. For example, the Mapper annotation of Mybatis is obtained in this way (see the source code org.mybatis. spring.boot.autoconfigure.MybatisAutoConfiguration.AutoConfiguredMapperScannerRegistrar#registerBeanDefinitions ).
Starter principle
The starter structure diagram is shown in the figure:
In the figure, we can see that the starter module mainly consists of two modules. Looking directly at the picture may be more abstract, here is an example.
spring-boot-starter-web is a commonly used starter for springbootweb development. From the above, it can be seen that the automatic configuration is actually scanning the corresponding automatic configuration class in the META-INF/spring.factories file under the spring-boot-autoconfigure package, so this The starter is definitely related to the spring-boot-autoconfigure package, but when we click on the dependency of spring-boot-starter-web, we will find that it does not have the package spring-boot-autoconfigure, but there is a dependency on the package spring-boot-starter. Click into this package and you will find the basic modules that most of the spring-boot-starter-xxx modules of this package depend on, as shown in the figure below:
The red line is the description of this package, which contains the basic functions of the starter
It can be seen from the above that the automatic configuration class must meet some conditions before it is imported into the container, such as whether there is a certain class - @ConditionalOnClass, here actually involves a problem, if we do not import some classes, why this This section of code will not report an error. Logically speaking, if there is no such class, then this keyword will become popular and fail to compile. This is because these files have been compiled into .class files, so no error will be reported. Then just It shows that the packages of these classes were actually included at the beginning of compilation, but they were removed later, so the spring-boot-autoconfigure package must contain all the dependencies of the classes that must meet the conditions. Check the pom dependencies of spring-boot-autoconfigure , I found that it is true, but these dependencies all contain the optional tag, which means that the dependency will not be passed, and the default is false.
Passing means that when C depends on B, and B chooses to depend on A, importing C will only import B, not A.
So when you first wrote the spring-boot-autoconfigure package, there were those dependencies, and since these dependencies are optional, when you introduce the starter spring-boot-starter-web , even if there are some non-web-related packages you don’t have Import, but still no error will be reported.
Since the spring-boot-starter-web starter will not be imported due to optional dependencies , the spring-boot-autoconfigure package will not be imported, so the spring-boot-starter-web starter must import web dependencies by itself , look at the pom file of spring-boot-starter-web and find that it is true, as shown below:
The red box contains commonly used web packages
To sum up , if you import the starter spring-boot-starter-web into your project , you will import spring-boot-autoconfigure to realize automatic configuration, and the package spring-boot-autoconfigure also contains other automatic configuration. The required dependencies, but due to optional dependencies, will not be imported into your project file, so that automatic configuration is perfectly realized.
This is also consistent with the initial diagram, spring-boot-starter-web as a starter module , spring-boot-autoconfigure as an autoconfigure module , the former depends on third-party components such as json, tomcat, the latter can optionally depend on these web dependencies, and then the former depends on the latter Or, by importing this starter, you can import the automatic configuration, and you can start the related automatic configuration. Of course, in addition to web-related dependencies, the spring-boot-autoconfigure package also relies on more, because it serves as an automatic configuration module for many starters, but due to optional dependencies, only when you import the corresponding starter module Only then will the corresponding automatic configuration take effect!