Springboot 自动配置流程
1.自动配置简介
springboot火了好几年,并以自身的简易特性,有着越来越广阔的使用市场;
核心: 提供缺省配置
spring实现原理: 封装了常见的第三方的工具,如mybatis,Rabbit,Elasticsearch等等,集成时,提供properties配置即可,相关的bean,由spring实现;
Spring根据一些生成条件 @ConditionXXX+ 配置信息(properties),决定是否自动配置这个组件;
eg:当我们提供了mybatis相关properties 并且 没有主动实现相关bean时,spring则根据相应的条件,实例化这些bean;即实现了自动配置;
2.实现方式
原理: 不仅仅是springboot,所有工具的自动配置,都是工具提供了默认实现;
通过简介,了解到:自动配置= @Conditional… + …Properties+其他;
2.1 从properties看起
spring官网提供了所有的自动配置属性,可参考:
https://docs.spring.io/spring-boot/docs/2.1.13.RELEASE/reference/htmlsingle/
从直观上我们看到,每种module,默认都有特定的名称前缀;springboot会加载绑定这些前缀的属性到对应配置下的实体bean;
2.2 进入主流程
springboot启动类注解@SpringBootApplication里面,有@EnableAutoConfiguration,这里面导入了具体操作类:@AutoConfigurationImportSelector
@Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME)
@Documented @Inherited @AutoConfigurationPackage
@Import(AutoConfigurationImportSelector.class) public @interface
EnableAutoConfiguration {
2.3 调用方法链
AutoConfigurationImportSelector 其中的方法链:
selectImports==>
getAutoConfigurationEntry==>
getCandidateConfigurations==>
org.springframework.core.io.support.SpringFactoriesLoader#loadFactoryNames ==>
loadSpringFactories
在loadSpringFactories方法中,会加载classpath路径下所有"META-INF/spring.factories"文件,不仅仅加载spring的,第三方和自定义的也会加载;这也为自定义starter提供了途径;
2.4 自动配置类
org.springframework.boot.autoconfigure.EnableAutoConfiguration对应一个列表,目前有100多个,他们有个共性,都是以xxxAutoConfiguration结尾,这就是各组件的自动配置,
2.5进入具体实现,以mybatis为例:
发现mybatis将自身的实现,也加入到了springboot的自动配置列表,org.springframework.boot.autoconfigure.EnableAutoConfiguration,这样算是交给spring管理了,按照2.3里的方法链,就实现了自动配置;
2.6进入MybatisAutoConfiguration
我们发现类上有@EnableConfigurationProperties(MybatisProperties.class)
和文中一些@Conditionalxxx注解
1. @EnableConfigurationProperties
该注解实现配置文件到JavaBean的映射,即将配置属性绑定到对应的实体bean上,即MybatisProperties里,这里前缀mybatis,这是默认的前缀,约束
2.@Conditionalxxx
该注解实现目标类,或方法,在@Conditional条件成立时才会执行;
eg:
@ConditionalOnClass({ SqlSessionFactory.class,
SqlSessionFactoryBean.class }) 表示:类路径下有这个文件,才会执行
@ConditionalOnBean(DataSource.class),表示spring上下文有这个bean,才会执行
@ConditionalOnMissingBean
表示spring上下文,没有这个bean,才会执行
这也是习惯优于配置的最终落地,
eg:当我们自己实现sqlSessionFactory时,优先使用我们自己的,当我们自己没有实现时,spring就会默认实现;
其他的conditional比如:
总结:
自动配置是springboot启动时,通过@EnableAutoConfiguration加载路径下的所有的META-INF/spring.factories,加载列表里的自动配置类都以xxxAutoConfiguration结尾,这些类上有对应的各自的属性javaBean,格式一般都是xxxProperties,用注解@EnableConfigurationProperties实现绑定,之后根据一些@Conditional条件,决定是否自动配置,还是用开发者自定义的;
3.springboot封装自定义starter
1.正常流程
核心: 自动配置= @Conditional… + …Properties+其他;
新建工程,这里用springboot演示 ,
1.1制作properties映射类:
1.2.制作autoConfiguration
1.3.将自动配置类加入到springboot自动配置列表
1.4 打包到仓库,在其他项目引入starter目录结构如下
1.5 添加需要的properties
1.6 通过debug启动,我们看到已经触发了自动配置
测试发现,这个UserProperties和UserAutoConfiguration类都是JavaConfig形式的Bean;
2.@Conditionalxxx作用在上面的1.5步骤中看到,当我们的properties提供齐全时,流程正常;
2.1 当properties不全时,
自动配置类并没有生效,符合预期;因为类上有@ConditionalOnProperty({“demo1.starter.begin”})
当属性存在时,才触发;
@ConditionalOnMissingBean({Test1.class})同理,当Test1的bean不存在时,才会初始化Test1,
总结:
封装一个starter就是默认提供实现,但开关留给了用户,
核心: 自动配置= @Conditional… + …Properties+其他;之前封装SDK,现在封装starter,各自有各自的场景,功能也有很大重叠的地方;
思考:两个是等于吗? 自动配置==SDK?
