共计 1209 个字符,预计需要花费 4 分钟才能阅读完成。
导读 | 最近在看 @ConditionalOnBean 的时候,看到了 ConfigurationCondition 接口,对这个接口比较陌生,故了解一下。 |
ConfigurationCondition 的定义是这样的,它继承了 Condition 类,如果读者对 Condition 类不不熟悉,可以在 Spring @Conditional 注解 详细讲解及示例 中了解。
package org.springframework.context.annotation;
public interface ConfigurationCondition extends Condition {ConfigurationCondition.ConfigurationPhase getConfigurationPhase();
// 可以翻译为构建阶段
public static enum ConfigurationPhase {
PARSE_CONFIGURATION,
REGISTER_BEAN;
private ConfigurationPhase() {}
}
}
接口中有一个 getConfigurationPhase 方法,用来返回 ConfigurationPhase 枚举类型。
先来看看 ConfigurationPhase 枚举类型:
它有两个值:
PARSE_CONFIGURATION:Condition 应评估 @Configuration 类,如果此时条件不匹配,@Configuration 则不会添加该类。
REGISTER_BEAN:该条件不会阻止 @Configuration 添加类,在评估条件时,所有 @Configurations 都将被解析。
ConfigurationPhase 的作用就是根据条件来判断是否加载这个配置类,OnBeanCondition(此注解的功能就是判断是否存在某个 bean,如果存在,则不注入标注的 bean 或者类)之所以返回 REGISTER_BEAN,是因为需要无论如何都要加载这个配置类(如果是 PARSE_CONFIGURATION,则有可能不加载),配置类中的 bean 的注入需要再根据 bean 的注入条件来判断。
再者,@onBeanCondition 的设计是想如果 matches 方法返回 true,则注入 bean,如果返回 false 则不注入 bean。如果枚举值选择了 PARSE_CONFIGURATION,matches 返回 false 整个配置将不被加载了,和设计有冲突。
实验证明,ConfigurationPhase 的作用并不是根据条件来判断是否加载这个配置类,实际 ConfigurationPhase 控制的是过滤的时机,是在创建 Configuration 类的时候过滤还是在创建 bean 的时候过滤(也可用条件注解的生效阶段来描述)。