泰州市统计局网站建设方案,wordpress页面调取,地下城封号做任务网站,高新区规划建设局网站条件注解相信各位小伙伴都用过#xff0c;Spring 中的多环境配置 profile 底层就是通过条件注解来实现的#xff0c;松哥在之前的 Spring 视频中也有和大家详细介绍过条件注解的使用#xff0c;感兴趣的小伙伴戳这里#xff1a;Spring源码应该怎么学#xff1f;。
从 Spr…条件注解相信各位小伙伴都用过Spring 中的多环境配置 profile 底层就是通过条件注解来实现的松哥在之前的 Spring 视频中也有和大家详细介绍过条件注解的使用感兴趣的小伙伴戳这里Spring源码应该怎么学。
从 Spring4.0 开始Spring 提供了一个更加细粒度的条件注解 ConfigurationCondition。从名字上就可以看出来这个是搭配 Configuration 注解一起使用的ConfigurationCondition 提供了一种更加细粒度的条件匹配可以在配置或者 Bean 注册的时候去评估条件注解是否满足。
也就是说当一个类上存在条件注解的时候我们可以有两个评估条件注解是否满足的时机
在配置的时候去评估。在 Bean 注册的时候评估。
在配置的时候评估可能会导致当前类都不会被加载在 Bean 注册的时候再去评估意味着当前类就会被加载。
1. ConfigurationCondition
我们先来看下这个类的定义
public interface ConfigurationCondition extends Condition {ConfigurationPhase getConfigurationPhase();enum ConfigurationPhase {PARSE_CONFIGURATION,REGISTER_BEAN}
}大家看到这里其实就是定义了两个枚举值然后提供了一个方法返回枚举值。
PARSE_CONFIGURATION这个表示 Condition 条件应该在解析 Configuration 类时进行评估如果评估不通过则不会将 Configuration 添加到容器中。REGISTER_BEAN这个表示添加常规 Bean 的时候去评估 Condition 条件常规 Bean 就是指非配置类例如添加搭配 Bean 注解使用的条件注解这个条件不会阻止注册 Configuration 类到容器中。
其实道理很好懂就是加载配置类的时候就根据条件注解判断要不要加载配置类还是等到注册 Bean 的时候再去看条件注解是否满足条件。
2. 案例分析
松哥通过一个简单案例来和小伙伴们演示一下。
假设我现在有如下条件
public class MyCondition implements ConfigurationCondition {Overridepublic ConfigurationPhase getConfigurationPhase() {return ConfigurationPhase.PARSE_CONFIGURATION;}Overridepublic boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {return context.getBeanFactory().containsBean(a);}
}这个条件我没有直接实现 Condition 接口而是实现类 ConfigurationCondition 接口在这个接口中getConfigurationPhase 方法返回了 PARSE_CONFIGURATION表示在加载配置类的时候就去评估条件是否满足matches 方法则是去判断容器中是否存在一个名为 a 的 Bean。
现在我有两个配置类分别是 A 和 B如下
Configuration
public class A {
}
Configuration
Conditional(MyCondition.class)
public class B {
}A 配置类正常加载B 配置类有一个加载条件就是得 A 存在B 才会加载。
现在在容器中加载 B 和 A 两个配置如下
AnnotationConfigApplicationContext ctx new AnnotationConfigApplicationContext();
ctx.register(B.class,A.class);
ctx.refresh();
String[] beanDefinitionNames ctx.getBeanDefinitionNames();
for (String beanDefinitionName : beanDefinitionNames) {System.out.println(beanDefinitionName);
}大家注意加载的时候我先加载了 B后加载了 A这点很重要加载 B 的时候由于此时容器中还不存在一个名为 a 的 Bean而我们的评估时机是在处理配置类的时候因此就会导致 B 配置类不会被加载最终打印出来的 BeanName 就没有 b。
但是如果我们将 MyCondition 中条件注解的评估时机改为 ConfigurationPhase.REGISTER_BEAN那么就表示在系统启动的时候并不会去评估条件注解是否满足而是会将 Configuration 配置类进行解析此时启动系统就会发现最终打印出来的 beanName 里既有 a 又有 b。
3. 源码分析
接下来我们再来从源码的角度来分析一下上述行为。
在 Spring 中提供了一个专门的内部类 ConditionEvaluator 来处理要不要跳过条件注解该类中有一个名为 shouldSkip 的方法用来处理此事
public boolean shouldSkip(AnnotatedTypeMetadata metadata) {return shouldSkip(metadata, null);
}
public boolean shouldSkip(Nullable AnnotatedTypeMetadata metadata, Nullable ConfigurationPhase phase) {if (metadata null || !metadata.isAnnotated(Conditional.class.getName())) {return false;}if (phase null) {if (metadata instanceof AnnotationMetadata annotationMetadata ConfigurationClassUtils.isConfigurationCandidate(annotationMetadata)) {return shouldSkip(metadata, ConfigurationPhase.PARSE_CONFIGURATION);}return shouldSkip(metadata, ConfigurationPhase.REGISTER_BEAN);}ListCondition conditions new ArrayList();for (String[] conditionClasses : getConditionClasses(metadata)) {for (String conditionClass : conditionClasses) {Condition condition getCondition(conditionClass, this.context.getClassLoader());conditions.add(condition);}}AnnotationAwareOrderComparator.sort(conditions);for (Condition condition : conditions) {ConfigurationPhase requiredPhase null;if (condition instanceof ConfigurationCondition configurationCondition) {requiredPhase configurationCondition.getConfigurationPhase();}if ((requiredPhase null || requiredPhase phase) !condition.matches(this.context, metadata)) {return true;}}return false;
}第一个方法不用多说我们来看第二个重载方法重载方法多了一个参数 ConfigurationPhase这个就表示配置的阶段也就是条件注解生效的阶段。
首先会去判断当前注解是否是一个条件注解如果不是条件注意那么就不能跳过要继续后面的解析继续后面的解析时 Bean 将会被注册如果是条件注解则继续后面的判断。继续判断如果没有传递 phase 进来说明没有指定应该在哪个阶段去评估条件注解那么这个时候就去判断如果当前注解是一个配置类上的注解那么就设置 phase 为 PARSE_CONFIGURATION然后继续调用 shouldSkip 方法否则就设置 phase 为 REGISTER_BEAN 然后继续调用 shouldSkip 方法。 那么什么样的情况会被认为是一个配置类上的注解呢如果当前类上添加的注解时 Component、ComponentScan、Import、ImportResource 以及这四种注解衍生出来的注解亦或者当前类中有 Bean 注解标记的方法那么当前类就是一个配置类就会设置 phase 为 PARSE_CONFIGURATION。 第二次进入 shouldSkip 方法的时候就已经有明确的 phase 了。这次进来后把所有的条件注解的条件收集起来存入到 conditions 集合中然后再对该集合进行排序。然后遍历该集合。遍历的时候就去判断这个条件注解是不是 ConfigurationCondition 类型的如果是则提取出来其中的 phase 为 requiredPhase这个就表示这个条件注意希望自己被处理的阶段接下来去判断如果 requiredPhase 为空说明条件并未指定自己的执行时间那么就执行 matches 方法进行条件评估如果 requiredPhase 不为空并且和传入的 phase 相等那么也是当前评估。其实这个判断核心逻辑就是以参数传入进来的 phase 为准要么条件没有设置评估时机要么设置了但是得和参数传进来的 phase 一致只有满足这两个条件才会当场进行评估。
这就是系统条件注解的评估逻辑。
对于配置类来说是在 AnnotatedBeanDefinitionReader#doRegisterBean 方法中调用评估逻辑的
private T void doRegisterBean(ClassT beanClass, Nullable String name,Nullable Class? extends Annotation[] qualifiers, Nullable SupplierT supplier,Nullable BeanDefinitionCustomizer[] customizers) {AnnotatedGenericBeanDefinition abd new AnnotatedGenericBeanDefinition(beanClass);if (this.conditionEvaluator.shouldSkip(abd.getMetadata())) {return;}//...
}调用的时候并未明确指定 phase所以会在进入到 shouldSkip 方法后自行分析是哪个阶段评估条件注解。
对于 Bean 注解标记的类来说是在 ConfigurationClassBeanDefinitionReader#loadBeanDefinitionsForBeanMethod 方法中调用评估逻辑的
private void loadBeanDefinitionsForBeanMethod(BeanMethod beanMethod) {ConfigurationClass configClass beanMethod.getConfigurationClass();MethodMetadata metadata beanMethod.getMetadata();String methodName metadata.getMethodName();if (this.conditionEvaluator.shouldSkip(metadata, ConfigurationPhase.REGISTER_BEAN)) {configClass.skippedBeanMethods.add(methodName);return;}//...
}这个调用的时候就传入了 phase 了直接指定了是在 Bean 初始化的时候评估。
好啦这就是条件注解条件评估时机的两种情况。在 Spring Boot 中定义的条件注解里有不少都用到了 ConfigurationCondition而不是传统的 Condition感兴趣的小伙伴可以自行查看哦
