目录

  1. 正常流程
  2. @Conditionalxxx作用

简介

由上篇文章<<springboot 自动配置 autoConfig 全流程>>了解到自动配置的原理和流程,本文演示一个自定义starter demo;

1.正常流程

核心: 自动配置= @Conditional… + …Properties+其他;

新建工程,这里用springboot演示 ,

1.1制作properties映射类:

springboot封装自定义starter

1.2.制作autoConfiguration

springboot封装自定义starter

1.3.将自动配置类加入到springboot自动配置列表

springboot封装自定义starter

1.4 打包到仓库,在其他项目引入starter

目录结构如下
springboot封装自定义starter

1.5 添加需要的properties

springboot封装自定义starter

1.6 通过debug启动,我们看到已经触发了自动配置

springboot封装自定义starter
测试发现,这个UserProperties和UserAutoConfiguration类都是JavaConfig形式的Bean;
springboot封装自定义starter

[email protected]作用

在上面的1.5步骤中看到,当我们的properties提供齐全时,流程正常;

2.1 当properties不全时,

springboot封装自定义starter
自动配置类并没有生效,符合预期;因为类上有@ConditionalOnProperty({“demo1.starter.begin”})
当属性存在时,才触发;
springboot封装自定义starter
@ConditionalOnMissingBean({Test1.class})同理,当Test1的bean不存在时,才会初始化Test1,
springboot封装自定义starter

总结:
封装一个starter就是默认提供实现,但开关留给了用户,
核心: 自动配置= @Conditional… + …Properties+其他;

之前封装SDK,现在封装starter,各自有各自的场景,功能也有很大重叠的地方;
思考:两个是等于吗? 自动配置==SDK?

相关文章: