SpringCloud配置⽂件l和l区别SpringCloud 配置⽂件 l和 l区别
作者其他技术⽂章
1)
2）
3）
4)
5)
6)
7）
8）
9)
10）
SpringBoot默认⽀持properties和YAML两种格式的配置⽂件。前者格式简单，但是只⽀持键值对。如果需要表达列表，最好使⽤YAML 格式。SpringBoot⽀持⾃动加载约定名称的配置⽂件，例如l。如果是⾃定义名称的配置⽂件，就要另⽅法了。可惜的是，不像前者有@PropertySource这样⽅便的加载⽅式，后者的加载必须借助编码逻辑来实现。
⼀、l（bootstrap.properties）与l（application.properties）执⾏顺序
⼆、典型的应⽤场景如下：
当使⽤ Spring Cloud Config Server 的时候，你应该在 l ⾥⾯指定 spring.application.name 和
fig.server.git.uri
和⼀些加密/解密的信息
技术上，l 是被⼀个⽗级的 Spring ApplicationContext 加载的。这个⽗级的 Spring ApplicationContext是先加载的，在加载l 的 ApplicationContext之前。
为何需要把 config server 的信息放在 l ⾥？
当使⽤ Spring Cloud 的时候，配置信息⼀般是从 config server 加载的，为了取得配置信息（⽐如密码等），你需要⼀些提早的或引导配置。因此，把 config server 信息放在 l，⽤来加载真正需要的配置信息。
三、⾼级使⽤场景
启动上下⽂
Spring Cloud会创建⼀个`Bootstrap Context`，作为Spring应⽤的`Application Context`的⽗上下⽂。初始化的时候，`Bootstrap Context`负责从外部源加载配置属性并解析配置。这两个上下⽂共享⼀个从外部获取的`Environment`。`Bootstrap`属性有⾼优先级，默认情况下，它们不会被本地配置覆盖。 `Bootstrap context`和`Application Context`有着不同的约定，所以新增了⼀个
`l`⽂件，⽽不是使⽤`l` (或者`application.properties`)。保证`Bootstrap Context`和`Application Context`配置的分离。下⾯是⼀个例⼦： **l**
spring:
application:
name: foo
cloud:
config:
uri: ${SPRING_CONFIG_URI:localhost:8888}
推荐在`l` or `l`⾥⾯配置`spring.application.name`. 你可以通过设置
`spring.abled=false`来禁⽤`bootstrap`。
应⽤上下⽂层次结构
如果你通过`SpringApplication`或者`SpringApplicationBuilder`创建⼀个`Application Context`，那么会为spring应⽤的`Application Context`创建⽗上下⽂`Bootstrap Context`。在Spring⾥有个特性，⼦上下⽂会继承⽗类的`property sources` and `profiles` ，所以`main application context` 相对于没有使⽤Spring Cloud Config，会新增额外的`property sources`。额外的`property
sources`有：
“bootstrap” : 如果在Bootstrap Context扫描到PropertySourceLocator并且有属性，则会添加到CompositePropertySource。
Spirng Cloud Config就是通过这种⽅式来添加的属性的，详细看源码ConfigServicePropertySourceLocator`。下⾯也也有⼀个例⼦⾃定义的例⼦。
“applicationConfig: [l]” ，（如果有spring.profiles.active=production则例如 app
licationConfig: [classpath:/l]#production）: 如果你使⽤l来配置Bootstrap Context，他⽐l优先级要低。它将添加到⼦上下⽂，作为Spring Boot应⽤程序的⼀部分。下⽂有介绍。
由于优先级规则，Bootstrap Context不包含从l来的数据，但是可以⽤它作为默认设置。
你可以很容易的扩展任何你建⽴的上下⽂层次，可以使⽤它提供的接⼝，或者使⽤SpringApplicationBuilder包含的⽅法
（parent()，child()，sibling()）。Bootstrap Context将是最⾼级别的⽗类。扩展的每⼀个Context都有有⾃⼰的bootstrap property
source（有可能是空的）。扩展的每⼀个Context都有不同spring.application.name。同⼀层层次的⽗⼦上下⽂原则上也有⼀有不同的名称，因此，也会有不同的Config Server配置。⼦上下⽂的属性在相同名字的情况下将覆盖⽗上下⽂的属性。
注意SpringApplicationBuilder允许共享Environment到所有层次，但是不是默认的。因此，同级的兄弟上下⽂不在和⽗类共享⼀些东西的时候不⼀定有相同的profiles或者property sources。
修改Bootstrap属性配置
源码位置BootstrapApplicationListener。
String configName = solvePlaceholders("${spring.cloud.bootstrap.name:bootstrap}");
String configLocation = solvePlaceholders("${spring.cloud.bootstrap.location:}");
Map<String, Object> bootstrapMap = new HashMap<>();bootstrapMap.put("fig.name",configName);
if(StringUtils.hasText(configLocation)){
bootstrapMap.put("fig.location", configLocation);
}
与fig.*类似，通过它的Environment来配置引导ApplicationContext。如果有⼀个激活的profile（来源于spring.profiles.active或
者Environment的Api构建），例如bootstrap-development.properties 就是配置了profile为development的配置⽂件.
覆盖远程属性
property sources被bootstrap context 添加到应⽤通常通过远程的⽅式，⽐如”Config Server”。默认情况下，本地的配置⽂件不能覆盖远
程配置，但是可以通过启动命令⾏参数来覆盖远程配置。如果需要本地⽂件覆盖远程⽂件，需要在远程配置⽂件⾥设置授权
fig.allowOverride=true（这个配置不能在本地被设置）。⼀旦设置了这个权限，你可以配置更加细粒度的配置来配置覆盖的
⽅式，
⽐如：
- fig.overrideNone=true 覆盖任何本地属性
- fig.overrideSystemProperties=false 仅仅系统属性和环境变量
源⽂件见PropertySourceBootstrapProperties
⾃定义启动配置
为什么使用bootstrap?bootstrap context是依赖/META-INF/spring.factories⽂件⾥⾯的org.springframework.cloud.bootstrap.BootstrapConfiguration条⽬下⾯，通过
逗号分隔的Spring  @Configuration类来建⽴的配置。任何main application context需要的⾃动注⼊的Bean可以在这⾥通过这种⽅式来获
取。这也是ApplicationContextInitializer建⽴@Bean的⽅式。可以通过@Order来更改初始化序列，默认是”last”。
# spring-cloud-context-1.1.1.RELEASE.jar
# spring.factories
# AutoConfiguration
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\ org.springframework.cloud.autoconfigure.ConfigurationPropertiesRebinderAutoConfig 警告
⼩⼼，你添加的⾃定义BootstrapConfiguration类没有错误的@ComponentScanned到你的主应⽤上下⽂，他们可能是不需要的。
使⽤⼀个另外的包不被@ComponentScan或者@SpringBootApplication注解覆盖到。
bootstrap context通过spring.factories配置的类初始化的所有的Bean都会在SpingApplicatin启动前加⼊到它的上下⽂⾥去。
⾃定义引导配置来源：Bootstrap Property Sources
默认的`property source`添加额外的配置是通过配置服务（Config Server），你也可以⾃定义添加`property source`通过实现
`PropertySourceLocator`接⼝来添加。你可以使⽤它加配置属性从不同的服务、数据库、或者其他。
下⾯是⼀个⾃定义的例⼦:
@Configuration
public class CustomPropertySourceLocator implements PropertySourceLocator {
@Override
public PropertySource<?> locate(Environment environment) {
return new MapPropertySource("customProperty",
Collections.<String, Object>singletonMap("property.from.sample.custom.source", "worked as intended"));
}
}
Environment被ApplicationContext建⽴，并传⼊property sources（可能不同个profile有不同的属性），所以，你可以从Environment寻
⼀些特别的属性。⽐如spring.application.name，它是默认的Config Server property source。
如果你建⽴了⼀个jar包，⾥⾯添加了⼀个META-INF/spring.factories⽂件：
org.springframework.cloud.bootstrap.BootstrapConfiguration=sample.custom.CustomPropertySourceLocator
那么，”customProperty“的PropertySource将会被包含到应⽤。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。