自动配置流程
# 110.自动配置流程
本篇博客来讲讲,生效的和不生效的配置,是如何工作的。
# AopAutoConfiguration
我们还是以 AopAutoConfiguration 为例:
package org.springframework.boot.autoconfigure.aop;
@Configuration(proxyBeanMethods = false)
@ConditionalOnProperty(prefix = "spring.aop", name = "auto", havingValue = "true", matchIfMissing = true)
public class AopAutoConfiguration {
@Configuration(proxyBeanMethods = false)
@ConditionalOnClass(Advice.class)
static class AspectJAutoProxyingConfiguration {
//............
}
@Configuration(proxyBeanMethods = false)
@ConditionalOnMissingClass("org.aspectj.weaver.Advice")
@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "true", matchIfMissing = true)
static class ClassProxyingConfiguration {
//............
}
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
解读:
- 第一个注解@Configuration,表明这是一个配置类,并且配置了 proxyBeanMethods 为 false
- 第二个注解:如果配置文件中,有配置 spring.aop.auto,并且值是 true,那么该配置才生效。
- 第二个注解最后一个参数 matchIfMissing,就是说即使没配置 spring.aop.auto,也认为是配置了,并且值是 true(也就是默认配置)
接下来是两个类:AspectJAutoProxyingConfiguration, ClassProxyingConfiguration
由于我们没有导入 Advice 类,因此该配置类 AspectJAutoProxyingConfiguration 不会生效,这里不讲;
ClassProxyingConfiguration:可以看到,如果没有 Advice 类的时候,那么该配置就会生效;然后判断是否配置了 spring.aop(即使没配,也生效),因此,开启的是简单的 AOP 功能。
综上,SpringBoot 默认开启了 AOP 功能,但是开启的是简单的 AOP,也就是必须得实现接口,或者有实现类,才能创建代理对象
# web 场景的自动配置
我们之前导入了 SpringMVC 的 starter,接下来我们分析下他们的自动配置
我们打开 spring-boot-autoconfigure-2.3.4.RELEASE.jar,
在 org.springframework.boot.autoconfigure.web.servlet
; 路径下,能看到不少配置类:
DispatcherServletAutoConfiguration
:SpringMVC 核心组件的自动配置
HttpEncodingAutoConfiguration
:配置了编码,避免乱码。
...........
# DispatcherServletAutoConfiguration
@AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE)
@Configuration(proxyBeanMethods = false)
@ConditionalOnWebApplication(type = Type.SERVLET)
@ConditionalOnClass(DispatcherServlet.class)
@AutoConfigureAfter(ServletWebServerFactoryAutoConfiguration.class)
public class DispatcherServletAutoConfiguration {
2
3
4
5
6
解读:
- 第一个注解:配置的是加载的顺序
- 第二个注解:@Configuration,表明这是一个配置类
- 第三个注解:@ConditionalOnWebApplication,表明这是一个 web 项目的时候,才有效,并且是原生 Servlet 的(SpringBoot 支持两种,一种是原生 Servlet;一种是响应式编程,导入的是 WebFlux)
- 第三个注解:就是 SpringMVC 的类,有的话才生效
- 第五个注解:在配置 ServletWebServerFactoryAutoConfiguration 后,再配置 DispatcherServletAutoConfiguration。也就是让 web 服务器先配好,然后再配置 Servlet
我们继续往下看:
@Configuration(proxyBeanMethods = false)
@Conditional(DefaultDispatcherServletCondition.class)
@ConditionalOnClass(ServletRegistration.class)
@EnableConfigurationProperties(WebMvcProperties.class)
protected static class DispatcherServletConfiguration {
@Bean(name = DEFAULT_DISPATCHER_SERVLET_BEAN_NAME)
public DispatcherServlet dispatcherServlet(WebMvcProperties webMvcProperties) {
DispatcherServlet dispatcherServlet = new DispatcherServlet();
dispatcherServlet.setDispatchOptionsRequest(webMvcProperties.isDispatchOptionsRequest());
dispatcherServlet.setDispatchTraceRequest(webMvcProperties.isDispatchTraceRequest());
dispatcherServlet.setThrowExceptionIfNoHandlerFound(webMvcProperties.isThrowExceptionIfNoHandlerFound());
dispatcherServlet.setPublishEvents(webMvcProperties.isPublishRequestHandledEvents());
dispatcherServlet.setEnableLoggingRequestDetails(webMvcProperties.isLogRequestDetails());
return dispatcherServlet;
}
2
3
4
5
6
7
8
9
10
11
12
13
14
15
解读:
- 第一个注解:表明这是一个配置类
- 第二个注解:后续再说
- 第三个注解:有 ServletRegistration 的时候才生效,而该类是 Tomcat 的内嵌包有的,因此会生效
- 第四个注解:开启 WebMvcProperties 类,和配置文件的绑定
WebMvcProperties 的部分源码:
@ConfigurationProperties(prefix = "spring.mvc")
public class WebMvcProperties {
2
也就是说,该类会和配置文件中,spring.mvc 开头的配置绑定起来(并且会放到容器中)。
我们可以试着打印下:
@SpringBootApplication
public class MainApplication {
public static void main(String[] args) {
ConfigurableApplicationContext run = SpringApplication.run(MainApplication.class, args);
String[] beanNamesForType = run.getBeanNamesForType(WebMvcProperties.class);
System.out.println("beanNamesForType: " + beanNamesForType.length);
}
}
2
3
4
5
6
7
8
9
运行结果:beanNamesForType: 1
下一步,就是 dispatcherServlet 方法,该方法上有个@Bean 注解,也就是会将 dispatcherServlet 放到容器中;然后方法体里,自己 new 了一个 dispatcherServlet,然后将 WebMvcProperties 里绑定的内容,配置到 dispatcherServlet 中。
至此,SpringMVC 的核心组件 dispatcherServlet,就配置完了
继续往下看:
@Bean
@ConditionalOnBean(MultipartResolver.class)
@ConditionalOnMissingBean(name = DispatcherServlet.MULTIPART_RESOLVER_BEAN_NAME)
public MultipartResolver multipartResolver(MultipartResolver resolver) {
// Detect if the user has created a MultipartResolver but named it incorrectly
return resolver;
}
2
3
4
5
6
7
可以看到还配置了文件上传的组件。解读:
- 第二个注解:有 MultipartResolver 类的时候才生效
- 第三个注解:如果组件,但是名字不是指定的名字的话(
multipartResolver
),那么就会生效
那么方法写的有点意思:传入了一个参数,然后返回该参数。
这是什么意思呢?在 SpringMVC 中,文件上传解析器必须得叫 multipartResolver
,而如果用户配错了,名字不叫这个,那么该方法也能找到用户配置的文件解析器,然后返回。而我们的方法名也是 multipartResolver,因此 bean 的名字也就是 multipartResolver。
综上,该方法的作用是规范化,防止有些用户配置的文件上传解析器不符合规范。
# HttpEncodingAutoConfiguration、
部分源码:
@Configuration(proxyBeanMethods = false)
@EnableConfigurationProperties(ServerProperties.class)
@ConditionalOnWebApplication(type = ConditionalOnWebApplication.Type.SERVLET)
@ConditionalOnClass(CharacterEncodingFilter.class)
@ConditionalOnProperty(prefix = "server.servlet.encoding", value = "enabled", matchIfMissing = true)
public class HttpEncodingAutoConfiguration {
@Bean
@ConditionalOnMissingBean
public CharacterEncodingFilter characterEncodingFilter() {
CharacterEncodingFilter filter = new OrderedCharacterEncodingFilter();
filter.setEncoding(this.properties.getCharset().name());
filter.setForceRequestEncoding(this.properties.shouldForce(Encoding.Type.REQUEST));
filter.setForceResponseEncoding(this.properties.shouldForce(Encoding.Type.RESPONSE));
return filter;
}
//.............
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
通过分析类上的注解,可以看到,即使没有配置 server.servlet.encoding,也会自动配置;
通过分析里面的方法,可以看到,如果用户没有配置 CharacterEncodingFilter,那么根据自动装配注解@ConditionalOnMissingBean,SpringBoot 会帮我们配置
SpringBoot 默认会在底层配好所有的组件。但是如果用户自己配置了以用户的优先
# 总结
SpringBoot 先加载所有的自动配置类 xxxxxAutoConfiguration
每个自动配置类按照条件进行生效(例如有 starter),默认都会绑定配置文件指定的值
生效的配置类就会给容器中装配很多组件,只要容器中有这些组件,相当于这些功能就有了
支持定制化配置:
- 用户可以自己替换底层的组件,例如加一个@Bean 注解,然后返回对象,
- 也可以通过配置 application.properties,来完成对象的配置(不用自己返回一个对象)。例如修改编码。具体怎么改,可以看 官网文档 (opens new window),或者看 jar 包里的配置文件,或 IDE 也有智能提示
- 一般来说,改配置文件就可以覆盖大部分场景。
# 最佳实践
后续我们要开发某个新功能,可以首先看看有没对应的 starter,有则引入(第三方的也可以)
然后我们可以查看自动配置了哪些(选做)
- 自己分析,引入场景对应的自动配置一般都生效了
- 在配置文件中 application.properties 中,加上一行 debug = true,就能开启自动配置报告,运行的时候会打印,例如哪个类生效了,哪个没生效
是否需要修改配置:参照文档修改配置项