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?