本文基于
Spring 5.1.7.release
SpringBoot 2.1.5.release
Spring 中的 @Condition 能非常方便幫助我們條件化的注冊(cè) bean逢净。這里我不做 @Conditional 相關(guān)注解的介紹短条。這里介紹下 Condition 的調(diào)用過(guò)程和一些注意事項(xiàng)育拨。
今天在看事務(wù)自動(dòng)配置類(lèi) TransactionAutoConfiguration 時(shí)發(fā)現(xiàn)靜態(tài)內(nèi)部類(lèi) EnableTransactionManagementConfiguration 的注冊(cè)并不是我預(yù)期的樣子宝惰， TransactionAutoConfiguration 的代碼如下：
package org.springframework.boot.autoconfigure.transaction;
...
...
/**
* {@link org.springframework.boot.autoconfigure.EnableAutoConfiguration
* Auto-configuration} for Spring transaction.
*
* @author Stephane Nicoll
* @since 1.3.0
*/
@Configuration
@ConditionalOnClass(PlatformTransactionManager.class)
@AutoConfigureAfter({ JtaAutoConfiguration.class, HibernateJpaAutoConfiguration.class,
DataSourceTransactionManagerAutoConfiguration.class,
Neo4jDataAutoConfiguration.class })
@EnableConfigurationProperties(TransactionProperties.class)
public class TransactionAutoConfiguration {
@Bean
@ConditionalOnMissingBean
public TransactionManagerCustomizers platformTransactionManagerCustomizers(
ObjectProvider<PlatformTransactionManagerCustomizer<?>> customizers) {
return new TransactionManagerCustomizers(
customizers.orderedStream().collect(Collectors.toList()));
}
@Configuration
@ConditionalOnSingleCandidate(PlatformTransactionManager.class)
public static class TransactionTemplateConfiguration {
private final PlatformTransactionManager transactionManager;
public TransactionTemplateConfiguration(
PlatformTransactionManager transactionManager) {
this.transactionManager = transactionManager;
}
@Bean
@ConditionalOnMissingBean
public TransactionTemplate transactionTemplate() {
return new TransactionTemplate(this.transactionManager);
}
}
@Configuration
@ConditionalOnBean(PlatformTransactionManager.class)
@ConditionalOnMissingBean(AbstractTransactionManagementConfiguration.class)
public static class EnableTransactionManagementConfiguration {
@Configuration
@EnableTransactionManagement(proxyTargetClass = false)
@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class",
havingValue = "false", matchIfMissing = false)
public static class JdkDynamicAutoProxyConfiguration {
}
@Configuration
@EnableTransactionManagement(proxyTargetClass = true)
@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class",
havingValue = "true", matchIfMissing = true)
public static class CglibAutoProxyConfiguration {
}
}
}
可以看到 EnableTransactionManagementConfiguration 使用了 ：
- @ConditionalOnBean(PlatformTransactionManager.class)
- @ConditionalOnMissingBean(AbstractTransactionManagementConfiguration.class)
起初我認(rèn)為如果 BeanFactory 中有 PlatformTransactionManager 且沒(méi)有 AbstractTransactionManagementConfiguration 才會(huì)進(jìn)入內(nèi)部進(jìn)行內(nèi)部的初始化（也就是說(shuō) @EnableTransactionManagement 注解不會(huì)起作用慧库，也就是說(shuō)不會(huì)進(jìn)入 TransactionManagementConfigurationSelector ）校套，但是當(dāng)我把 PlatformTransactionManager 的 bean 定義去除后毅待，發(fā)現(xiàn)還是會(huì)進(jìn)入到 TransactionManagementConfigurationSelector，這使我很疑惑。經(jīng)過(guò)一系列 debug 后終于找到了原因窟她。
Condition 原理
首先所有的 Configuration 都會(huì)被 ConfigurationClassPostProcessor#postProcessBeanDefinitionRegistry 處理，之后會(huì)被 ConfigurationClassParser#parse(Set<BeanDefinitionHolder> configCandidates) 解析蔼水。在解析時(shí)會(huì)調(diào)用 ConditionEvaluator#shouldSkip 判斷是否需要把目標(biāo)解析為 ConfigurationClass礁苗，解析時(shí)的判斷源碼如下：
1. ConfigurationClassParser#parse -> ConfigurationClassParser#processConfigurationClass
protected void processConfigurationClass(ConfigurationClass configClass) throws IOException {
if (this.conditionEvaluator.shouldSkip(configClass.getMetadata(), ConfigurationPhase.PARSE_CONFIGURATION)) {
return;
}
ConfigurationClass existingClass = this.configurationClasses.get(configClass);
if (existingClass != null) {
if (configClass.isImported()) {
if (existingClass.isImported()) {
existingClass.mergeImportedBy(configClass);
}
// Otherwise ignore new imported config class; existing non-imported class overrides it.
return;
}
else {
// Explicit bean definition found, probably replacing an import.
// Let's remove the old one and go with the new one.
this.configurationClasses.remove(configClass);
this.knownSuperclasses.values().removeIf(configClass::equals);
}
}
// Recursively process the configuration class and its superclass hierarchy.
SourceClass sourceClass = asSourceClass(configClass);
do {
sourceClass = doProcessConfigurationClass(configClass, sourceClass);
}
while (sourceClass != null);
this.configurationClasses.put(configClass, configClass);
}
shouldSkip 判斷是否跳過(guò) configClass 的解析，注意這里使用的是ConfigurationPhase.PARSE_CONFIGURATION徙缴，這也是為什么我之前的以為是錯(cuò)誤的原因试伙。
ConfigurationPhase.PARSE_CONFIGURATION 表示 Condition 只有在解析階段才起作用，也就是說(shuō) Condition 不是 ConfigurationCondition 的實(shí)現(xiàn)或者階段不匹配都不會(huì)跳過(guò)
2. shouldSkip
/**
* false： 不跳過(guò)于样，true：跳過(guò)
*/
public boolean shouldSkip(@Nullable AnnotatedTypeMetadata metadata, @Nullable ConfigurationP
// metadata == null 或 沒(méi)有注解 @Conditional 相關(guān)的類(lèi)疏叨，直接返回 false
if (metadata == null || !metadata.isAnnotated(Conditional.class.getName())) {
return false;
}
// 如果 phase （階段為空），判斷類(lèi)上是否有 @Configuration穿剖， @Component蚤蔓，@ComponentScan，@Import糊余，@ImportResource
// 或方法上有 @Bean 注解秀又，如果有就使用 ConfigurationPhase.PARSE_CONFIGURATION)
if (phase == null) {
if (metadata instanceof AnnotationMetadata &&
ConfigurationClassUtils.isConfigurationCandidate((AnnotationMetadata) metada
return shouldSkip(metadata, ConfigurationPhase.PARSE_CONFIGURATION);
}
return shouldSkip(metadata, ConfigurationPhase.REGISTER_BEAN);
}
List<Condition> conditions = new ArrayList<>();
// 獲取 @Conditional 注解對(duì)應(yīng)得 Condtion 放入 conditions，這里使用了反射
for (String[] conditionClasses : getConditionClasses(metadata)) {
for (String conditionClass : conditionClasses) {
Condition condition = getCondition(conditionClass, this.context.getClassLoader()
conditions.add(condition);
}
}
// 排序
AnnotationAwareOrderComparator.sort(conditions);
// 遍歷 Condition 判斷是否應(yīng)該跳過(guò)
for (Condition condition : conditions) {
ConfigurationPhase requiredPhase = null;
// 如果 Condition 實(shí)現(xiàn)了 ConfigurationCondition 則獲取該 Condition 得階段
if (condition instanceof ConfigurationCondition) {
requiredPhase = ((ConfigurationCondition) condition).getConfigurationPhase();
}
// 如果 (requiredPhase == null || 階段匹配 ) && matches 返回 false 就返回 true
// 如果 requiredPhase != null && 階段不匹配 直接返回 false
if ((requiredPhase == null || requiredPhase == phase) && !condition.matches(this.context, metadata)) {
return true;
}
}
return false;
}
看到這我們會(huì)看
- @ConditionalOnBean(PlatformTransactionManager.class)
@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Conditional(OnBeanCondition.class)
public @interface ConditionalOnBean {
- @ConditionalOnMissingBean(AbstractTransactionManagementConfiguration.class)
@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Conditional(OnBeanCondition.class)
public @interface ConditionalOnMissingBean {
可以看到這兩個(gè) @Conditonal 都是用得是 OnBeanCondition 來(lái)處理贬芥。翻看源碼發(fā)現(xiàn) OnBeanCondition 實(shí)現(xiàn)了 ConfigurationCondition吐辙，它的處理階段是 ConfigurationPhase.REGISTER_BEAN（也就是注冊(cè)階段）。
看到這蘸劈，相信大家對(duì)整個(gè)得 Condition 處理邏輯有了大概得了解昏苏，也明白為什么我起初得錯(cuò)誤是錯(cuò)誤的吧。
Conclusion
在使用 @Condtional 相關(guān)注解時(shí)需要注意對(duì)應(yīng)的 Condition 起作用的階段，防止使用錯(cuò)誤贤惯。
