本文基于
Spring 5.1.7.release
SpringBoot 2.1.5.release
Spring 中的 @Condition 能非常方便幫助我們條件化的注冊 bean。這里我不做 @Conditional 相關(guān)注解的介紹。這里介紹下 Condition 的調(diào)用過程和一些注意事項。
今天在看事務(wù)自動配置類 TransactionAutoConfiguration 時發(fā)現(xiàn)靜態(tài)內(nèi)部類 EnableTransactionManagementConfiguration 的注冊并不是我預(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)
起初我認為如果 BeanFactory 中有 PlatformTransactionManager 且沒有 AbstractTransactionManagementConfiguration 才會進入內(nèi)部進行內(nèi)部的初始化（也就是說 @EnableTransactionManagement 注解不會起作用，也就是說不會進入 TransactionManagementConfigurationSelector ），但是當(dāng)我把 PlatformTransactionManager 的 bean 定義去除后，發(fā)現(xiàn)還是會進入到 TransactionManagementConfigurationSelector，這使我很疑惑。經(jīng)過一系列 debug 后終于找到了原因。
Condition 原理
首先所有的 Configuration 都會被 ConfigurationClassPostProcessor#postProcessBeanDefinitionRegistry 處理，之后會被 ConfigurationClassParser#parse(Set<BeanDefinitionHolder> configCandidates) 解析。在解析時會調(diào)用 ConditionEvaluator#shouldSkip 判斷是否需要把目標(biāo)解析為 ConfigurationClass，解析時的判斷源碼如下：
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 判斷是否跳過 configClass 的解析，注意這里使用的是ConfigurationPhase.PARSE_CONFIGURATION，這也是為什么我之前的以為是錯誤的原因。
ConfigurationPhase.PARSE_CONFIGURATION 表示 Condition 只有在解析階段才起作用，也就是說 Condition 不是 ConfigurationCondition 的實現(xiàn)或者階段不匹配都不會跳過
2. shouldSkip
/**
* false： 不跳過，true：跳過
*/
public boolean shouldSkip(@Nullable AnnotatedTypeMetadata metadata, @Nullable ConfigurationP
// metadata == null 或 沒有注解 @Conditional 相關(guān)的類，直接返回 false
if (metadata == null || !metadata.isAnnotated(Conditional.class.getName())) {
return false;
}
// 如果 phase （階段為空），判斷類上是否有 @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 注解對應(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)該跳過
for (Condition condition : conditions) {
ConfigurationPhase requiredPhase = null;
// 如果 Condition 實現(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;
}
看到這我們會看
- @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 {
可以看到這兩個 @Conditonal 都是用得是 OnBeanCondition 來處理。翻看源碼發(fā)現(xiàn) OnBeanCondition 實現(xiàn)了 ConfigurationCondition，它的處理階段是 ConfigurationPhase.REGISTER_BEAN（也就是注冊階段）。
看到這，相信大家對整個得 Condition 處理邏輯有了大概得了解，也明白為什么我起初得錯誤是錯誤的吧。
Conclusion
在使用 @Condtional 相關(guān)注解時需要注意對應(yīng)的 Condition 起作用的階段，防止使用錯誤。
