快捷導(dǎo)航

基于Spring框架由ConditionalOnMissingBean注解引發(fā)的問(wèn)題

更新時(shí)間：2023年11月27日 10:39:30 作者：愛(ài)藝欣聊編程

這篇文章主要介紹了基于Spring框架由ConditionalOnMissingBean注解引發(fā)的問(wèn)題,具有很好

問(wèn)題描述

最新負(fù)責(zé)的工程在做dubbo配置disconf靜態(tài)配置托管優(yōu)化，由一個(gè)StaticConfigPropertiesFactoryBean來(lái)讀取靜態(tài)配置，它是PropertiesFactoryBean的一個(gè)子類，讀取到的所有配置放在一個(gè)Properties中。

dubbo配置直接引用這個(gè)Properties的值。

像下面這樣，dubbo接口的group通過(guò)disconf的靜態(tài)配置項(xiàng)dubbo.hst.pay.group定義：

工程使用Spring Boot框架，Spring版本號(hào)4.1.1，Spring Boot版本號(hào)1.1.9，spring-security版本號(hào)4.0.2，啟用了Spring Boot框架的Anto Configuration特性。

StaticConfigPropertiesFactoryBean這個(gè)bean的configSrc屬性值是個(gè)占位符，值在外部配置文件定義。

但是啟動(dòng)工程時(shí)出現(xiàn)了一個(gè)問(wèn)題，拋出了一個(gè)IllegalArgumentException異常，異常日志如下：

Caused by: java.lang.IllegalArgumentException: configSrc error : ${disconf.configSrc}
at com.baidu.disconf.client.haitao.properties.StaticConfigPropertiesFactoryBean.createProperties(StaticConfigPropertiesFactoryBean.java:65)
at org.springframework.beans.factory.config.PropertiesFactoryBean.afterPropertiesSet(PropertiesFactoryBean.java:71)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1633)
at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1570)
... 35 more

排查過(guò)程

從日志中看到configSrc這個(gè)屬性的值不滿足條件導(dǎo)致拋出了這個(gè)異常，而且值是${disconf.configSrc}，這里比較奇怪，在初始化bean的時(shí)候框架不是會(huì)對(duì)占位符進(jìn)行解析求職處理的么，什么原因?qū)е抡嘉环幢惶幚韇ean就開(kāi)始初始化了？

我們知道Spring框架由PropertySourcesPlaceholderConfigurer來(lái)處理占位符，PropertySourcesPlaceholderConfigurer是一個(gè)BeanFactoryPostProcessor，在容器所有BeanDefinition被加載之后，bean初始化之前，BeanFactoryPostProcessor會(huì)被激活，PropertySourcesPlaceholderConfigurer會(huì)加載所有被引入的屬性文件，并且查找占位符對(duì)應(yīng)的值，并把對(duì)應(yīng)的值設(shè)置到bean屬性對(duì)應(yīng)的PropertyValue中，這樣在bean初始化時(shí)設(shè)置每個(gè)屬性的值時(shí)設(shè)置的就是處理后的值了。

org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory, List)

就是這在觸發(fā)這個(gè)BeanFactoryPostProcessor的，注意代碼行數(shù)是162行。

但是現(xiàn)在的現(xiàn)象是configSrc這個(gè)屬性初始化之后卻是未處理的占位符字符串。

分析原因有兩種可能，第一種disconf.configSrc這個(gè)配置項(xiàng)在文件中未定義或未被容器加載，第二種StaticConfigPropertiesFactoryBean在屬性占位符處理之前就初始化了。

第一種原因很容易就排除了，disconf.configSrc這個(gè)配置項(xiàng)已經(jīng)定義了，在這次修改之前就已存在之前一直都是沒(méi)問(wèn)題的，且由于ignoreUnresolvablePlaceholders這個(gè)設(shè)置默認(rèn)是false，就算它未被定義容器也會(huì)提前拋出IllegalArgumentException異常：

org.springframework.util.PropertyPlaceholderHelper.parseStringValue(String, PlaceholderResolver, Set)

所以只能是第二種原因了，那就是StaticConfigPropertiesFactoryBean在屬性占位符處理之前就被容器初始化了。Spring框架如此龐大，要找原因最有效的手段就是debug了，把斷點(diǎn)打到StaticConfigPropertiesFactoryBean初始化代碼處，看它是從哪進(jìn)來(lái)的：

org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(ConfigurableListableBeanFactory, List)

通過(guò)debug發(fā)現(xiàn)，這個(gè)bean的初始化也是從BeanFactoryPostProcessor調(diào)進(jìn)去的，而且看下代碼是94行，在占位符處理的164行前面，好了，這里可以解釋configSrc值為什么是錯(cuò)的。

但是這些BeanFactoryPostProcessor是干嘛的？為什么在其它BFPP激活之前就去初始化bean了。

看一下這個(gè)BFPP是什么：

這個(gè)BFPP是ConfigurationClassPostProcessor，當(dāng)應(yīng)用使用了annotation-config或component-scan掃描注解bean時(shí)，容器會(huì)自動(dòng)注冊(cè)一個(gè)ConfigurationClassPostProcessor來(lái)加載注解定義的BeanDefinition，按常理，這個(gè)BFPP也只會(huì)生成BeanDefinition，不會(huì)執(zhí)行bean初始化動(dòng)作。

那么是什么地方導(dǎo)致bean發(fā)生初始化了呢？

再看下上面哪個(gè)調(diào)用棧，在OnMissingBeanCondition.matches之后就調(diào)用BeanFactory的getBeansXXX了，然后一步一步觸發(fā)了createBean。

那這個(gè)OnMissingBeanCondition從哪來(lái)的呢？

從debug的情況來(lái)看跟WebMvcSecurityConfiguration有關(guān)。

看下WebMvcSecurityConfiguration這個(gè)類，它有一個(gè)@ConditionalOnMissingBean注解，這個(gè)注解作用在bean定義上，它的作用就是在容器加載它作用的bean時(shí)，檢查容器中是否存在目標(biāo)類型（ConditionalOnMissingBean注解的value值）的bean了，如果存在這跳過(guò)原始bean的BeanDefinition加載動(dòng)作。

上面說(shuō)的那段邏輯就是由OnMissingBeanCondition.matches來(lái)完成的。

也就是說(shuō)上面那整棵調(diào)用樹(shù)所做的事情就是檢查容器知否已存在RequestDataValueProcessor類型的bean，如果存在則不再重復(fù)重新加載這個(gè)RequestDataValueProcessor，如果是普通的bean那還好辦直接比較bean的類型是否是RequestDataValueProcessor類型就行了，不必去初始化整個(gè)bean，但是如果是FactoryBean那就壞事了，因?yàn)镕actoryBean類型的bean最終創(chuàng)建的bean的類型并不是FactoryBean本身的類型，而是由它的getObject返回值來(lái)決定的，所以要拿到bean類型，會(huì)調(diào)它的getObject方法創(chuàng)建bean之后再比較類型。

而dubbo消費(fèi)者bean的類型都是com.alibaba.dubbo.config.spring.ReferenceBean，這恰恰是一個(gè)FactoryBean，此時(shí)會(huì)初始化消費(fèi)者bean，設(shè)置group屬性時(shí)接著初始化引用的的disconfPropertiesReader bean，所以就導(dǎo)致了悲劇。

org.springframework.beans.factory.support.AbstractBeanFactory.isTypeMatch

最后只剩下最后一個(gè)問(wèn)題，WebMvcSecurityConfiguration是從哪來(lái)的，搜索代碼，直接宣布結(jié)果：

由于工程使用了AutoConfiguration特性，框架查找并讀取所有名稱是*AutoConfiguration的類，所以會(huì)找到SecurityAutoConfiguration。

這個(gè)類定義了@Configuration注解，所以會(huì)加載這個(gè)類中定義的bean，發(fā)現(xiàn)了@Import注解，根據(jù)這個(gè)標(biāo)簽讀取到并解析SpringBootWebSecurityConfiguration，繼續(xù)讀取到它的內(nèi)部類WebMvcSecurityConfigurationConditions，再讀取到內(nèi)部類的內(nèi)部類DefaultWebMvcSecurityConfiguration，這個(gè)內(nèi)部類上有@EnableWebMvcSecurity注解，這個(gè)注解又@Import了WebMvcSecurityConfiguration，這個(gè)類有@EnableWebSecurity注解，注解@Import了SpringWebMvcImportSelector，這個(gè)ImportSelector會(huì)導(dǎo)入org.springframework.security.config.annotation.web.configuration.WebMvcSecurityConfiguration：

總結(jié)產(chǎn)生問(wèn)題的最終原因：

是因?yàn)楣こ淌褂昧薙pring Boot的Auto Configuration功能，而根據(jù)這個(gè)工程的特點(diǎn)會(huì)自動(dòng)加載安全配置SecurityAutoConfiguration，由此經(jīng)過(guò)一系列的直接或間接的import，會(huì)導(dǎo)致框架讀取WebMvcSecurityConfiguration，而這個(gè)配置在加載RequestDataValueProcessor這個(gè)bean定義的時(shí)候由于有@ConditionalOnMissingBean的作用導(dǎo)致框架會(huì)檢查容器中是否已經(jīng)存在了RequestDataValueProcessor類型的bean實(shí)例，在檢查的過(guò)程中當(dāng)掃描到sendCouponRemoteApiImpl這個(gè)dubbo消費(fèi)者bean時(shí)，由于它是一個(gè)FactoryBean，getObject方法會(huì)被調(diào)用進(jìn)而執(zhí)行了bean的初始化動(dòng)作，而由于此時(shí)由于處理屬性占位符的PropertySourcesPlaceholderConfigurer還未被激活，所以導(dǎo)致bean的屬性值沒(méi)有被正確初始化。

解決方案

治標(biāo)的方案，考慮到工程主要是提供dubbo服務(wù)無(wú)需啟用安全配置，可以禁調(diào)安全配置的自動(dòng)加載，@EnableAutoConfiguration注解有exclude屬性，通過(guò)它可以禁用對(duì)SecurityAutoConfiguration的自動(dòng)加載：