知识边界
ApplicationContext向上衍生 6大接口体系。
衍生点
- PropertyResolver具体的体系
- ConfigurableConversionService 体系
- @Profile
- PropertySourcesPlaceholderConfigurer
- MutablePropertySources
- PropertySources SystemProperties SystemEnvironment
EnvironmentCapable体系
EnvironmentCapable 暴露了环境接口。所有的ApplicationContext的实现都是实现这个接口的。这个接口最初是用来检查可能在上下文中或者不在上下文中的和环境交互的实例。正如前面提到了 ApplicationContext 继承了 EnvironmentCapable 所以暴露了 getEnvironment方法，然而ConfigurableApplicationContext重新覆盖了这个方法，并且返回的是ConfigurableEnvironment。事实上 Environment是只读的。ConfigurableApplicationContext是可以被配置的。
体系类图：
environment类图.png
PropertyResolver
针对任意的潜在资源解析属性的接口。
结构.png
resolvePlaceholders方法：
为了解决 输出具体的值。
ConfigurablePropertyResolver
配置接口是有大多数（如果不是全部的话）PropertyResolver的实现类实现的。提供访问和自定义在将属性值从一种类型转换为另一种类型时使用的“转换服务”的工具。
image.png
Environment
表示当前应用所在环境的接口。代表环境的两个key：profiles和properties。通过PropertyResolver的子接口暴露与属性访问相关的方法。
profile表示容器中要加载bean定义的逻辑组合 当且仅当当前profile是激活状态的。bean通常在xml或者注解定义的时候就会归属于profile。可以查看 @Profile注解了解详细的细节。Environment类相对于profile的作用的决定哪一个profile是激活的，哪一个是默认激活的。
Properties在几乎所有的应用中扮演了一个重要的角色。也会从很多个途径中组织。properties files, JVM system properties, system environment variables, JNDI, servlet context parameters, ad-hoc Properties objects。对于properties来说，Environment的作用就是给用户提供了一个便利的Api接口，从各种不同的文件中来加载配置。应用上下文中的Bean将会继承EnvironmentAware或者使用@Inject来查询Profile的状态和直接操作properties。然而在大多数情况下，应用级的bean不需要直接的使用Environment，但是又类似${}这种值需要被替换。比如PropertySourcesPlaceholderConfigurer 他本省是EnvironmentAware 自从spring3.1的版本之后使用context:property-placeholder会自动的注册环境。
通过ConfigurableEnvironment来配置环境变量，在AbstractApplicationContext的所有子类中的getEnvironment方法配置。
image.png
ConfigurableEnvironment
给几乎所有的Environment类型的接口实现可配置的接口。提供了设置激活的Profile和默认的Profile和操纵基础属性资源，允许用户校验和设置需要的属性。通过ConfigurablePropertyResolver的子类定制转换服务。
操作基础属性资源
这些属性资源可以被删除，排序或者替换。额外的属性资源可以通过MutablePropertySources的getPropertySources方法来添加。
下面的例子是针对{@link StandardEnvironment}实现的{@code ConfigurableEnvironment}，但通常适用于任何实现，尽管特定的默认属性资源可能不同
1、添加最高搜索优先级的属性资源
ConfigurableEnvironment environment = new StandardEnvironment();
MutablePropertySources propertySources = environment.getPropertySources();
Map<String, String> myMap = new HashMap<>();
myMap.put("xyz", "myValue");
propertySources.addFirst(new MapPropertySource("MY_MAP", myMap));
2、删除默认的系统的属性资源
MutablePropertySources propertySources = environment.getPropertySources();
propertySources.remove(StandardEnvironment.SYSTEM_PROPERTIES_PROPERTY_SOURCE_NAME)
3、为了测试的目的而模拟系统环境
MockPropertySource mockEnvVars = new MockPropertySource().withProperty("xyz", "myValue");
propertySources.replace(StandardEnvironment.SYSTEM_ENVIRONMENT_PROPERTY_SOURCE_NAME, mockEnvVars);
当一个Environment被应用上下文使用的时候，这意味着在refresh方法执行之前对于PropertySource的操作都会处理。特别强调的是在启动期间包括PropertySourcesPlaceholderConfigurer加载的所有的资源都是可见的
ConfigurableEnvironment类结构.png
merge：
该方法是把父环境的Active Profile 默认的Profile 和属性资源 合并到各自的子环境中。对于任意的属性资源，如果父环境存在，子环境也存在，那么父环境会被丢弃，子环境会被保留。激活和默认的配置文件名称也会对重复的配置文件进行过滤，以避免混淆和冗余存储。父环境的内容一般是只读的，在merge之后父环境的改变不会同步到子环境中。
AbstractEnvironment
Environment的抽象基类。通过ACTIVE_PROFILES_PROPERTY_NAME和DEFAULT_PROFILES_PROPERTY_NAME属性来指定活动配置文件和默认配置文件。
具体子类的不同主要在于添加PropertySource对象。AbstractEnvironment不会添加。子类需要通过customizePropertySources方法扩展属性资源。使用者应该使用{@link ConfigurableEnvironment#getPropertySources()}自定义
以及处理{@link MutablePropertySources} API
AbstractEnvironment类结构.png
AbstractEnvironment类结构2.png
StandardEnvironment
在 ‘标准’（一般） 的应用上下文中 Environment接口的实现类
除了ConfigurableEnvironment的一般功能之外，还包括以下功能
属性解析和与概要文件相关的操作，此实现配置两个
默认属性源，按以下顺序搜索
AbstractEnvironment#getSystemProperties()
AbstractEnvironment#getSystemEnvironment()
也就是说，如果键“xyz”同时存在于JVM系统属性和当前流程的环境变量集中，则来自系统属性的键“xyz”的值将从对{@code environment. getproperty(“xyz”)}的调用中返回。默认情况下选择这种顺序，因为系统属性是针对每个jvm的，而环境变量在给定系统上的多个jvm之间可能是相同的。系统属性优先级允许在每个jvm的基础上重写环境变量。
这些默认的资源可以被删除，排序和替换，其他资源可以使用MutablePropertySources的getPropertySources方法
网友评论