Spring Cloud 提供了更多功能作为两个库:Spring Cloud Context 和 Spring Cloud Commons。
- Spring Cloud Context 为
ApplicationContext
Spring Cloud 应用程序(引导上下文、加密、刷新范围和环境端点)提供实用程序和特殊服务。 - Spring Cloud Commons 是在不同的 Spring Cloud 实现(例如 Spring Cloud Netflix 和 Spring Cloud Consul)中使用的一组抽象和通用类。
那么他为啥要再启动一个容器,启动的这个容器都做了什么?
- PropertySourceBootstrapConfiguration
- 这就是那个解析 cloud config 的初始化器
- EncryptionBootstrapConfiguration
- Spring 内置了加解密,支持对称加密和非对称加密。使用对称加密只需要在bootstrap.yml文件中通过
encrypt.key
属性指定加密用的密钥,这样SpringCloud就会自动创建一个org.springframework.security.crypto.encrypt.TextEncryptor
类型的bean。 - 其中可以解析配置文件中加密配置的 bean EnvironmentDecryptApplicationInitializer 也是这个配置类注入的。
- Spring 内置了加解密,支持对称加密和非对称加密。使用对称加密只需要在bootstrap.yml文件中通过
- ConfigurationPropertiesRebinderAutoConfiguration
- 与属性动态刷新(@RefreshScope)相关
- 监听 EnvironmentChangeEvent,然后绑定那些我们已经用 ConfigrationProperties 绑定过的 beans。
- 其他两个(wo ye)不重(zhi)要(dao)...
总结一下:创建这个父容器是为了从 spring.factories 文件中解析出 @BootstrapConfiguration 对应的自动配置类,准备一些后续需要使用到的bean。
然后又启动了一圈又回来了。
这些initializer啥时候被调用的呢?
所以,总结一下 BootstrapApplicationListener 主要做了 2 件事:
- 启动了自己的父容器,从 spring.factories 文件中解析出 @BootstrapConfiguration 对应的自动配置类,准备一些后续需要使用到的bean。
- 为 SpringApplication 添加了一些初始化器,在”子“容器启动前做一些事情
接下来看一下其中一个比较重要的初始化器 PropertySourceBootstrapConfiguration,他主要是用来解析 cloud config 的。
上面那个是加载远程文件的,本地的 bootstrap* 文件是在“父”容器启动时触发 ApplicationEnvironmentPreparedEvent 然后到了监听器 ConfigFileApplicationListener 来加载的。
因为BootstrapApplicationListener排在第一位,他又启动了“父”容器,所以第一次启动时并没有执行到 ConfigFileApplicationListener,第一次执行 ConfigFileApplicationListener 是“父”容器,
- file: ./config/ & file:./ 为了 java -jar 启动时读取 jar 包外的配置
- classpath:/config/ & classpath:/ 读取类路径下的配置
todo
- 可能与参数动态刷新有关,可以研究下日后,用于xadmin
- 突然觉得日志的配置要放到bootstrap.yml中一份了(application可以覆盖吗?)
-
why?
配置文件覆盖优先级?