深入Spring配置项问题,全面解析

本文就Spring配置项解析问题展开分析,这其中涉及到bean定义注册表后置处理、bean工厂后置处理、工厂bean等Spring相关的概念。本文将以上述问题作为切入点,进行分析和展开介绍。

问题背景介绍

我们的项目中某次依赖了某个第三方包及其中的XML文件,相关代码如下所示:XML文件中定义了Mybatis相关的bean,以及对自定义数据源myDataSource的引用。在@Configuration配置类中,我们引入了XML文件,并通过@Bean注解的方式声明了数据源bean。
<!-- 配置SqlSessionFactoryBean -->
<bean id="thirdPartySqlSessionFactory"
      class="org.mybatis.spring.SqlSessionFactoryBean"
      depends-on="myDataSource">
    <!-- datasource为自定义数据源 -->
    <property name="dataSource" ref="myDataSource"/>
    <property name="mapperLocations" value="classpath:mybatis/third-party/*.xml"/>
</bean>

<!-- 配置MapperScannerConfigurer -->
<bean id="thirdPartyMapperScannerConfigurer"
      class="org.mybatis.spring.mapper.MapperScannerConfigurer"
      depends-on="thirdPartySqlSessionFactory">
    <property name="basePackage" value="com.alibaba.thirdparty.dao"/>
    <property name="sqlSessionFactoryBeanName" value="thirdPartySqlSessionFactory"/>
</bean>
 
@Configuration
@EnableTransactionManagement(proxyTargetClass = true)
// 引入上述XML文件
@ImportResource("classpath*:/mybatis-third-party-config.xml")
public class MyDataSourceConfiguration {

    // 声明自定义数据源
    @Bean(name = "myDataSource")
    public DataSource createMyDataSource(Environment env) {
        // 返回数据源实例,具体代码略
    }
    
}

项目启动后,我们发现一个原有的通过XML定义的HSF(HSF全称High-speed Service Framework,是阿里内部主要使用的RPC服务框架)客户端bean中的配置项无法被正常解析。由于这是一个与我们新引入的包无关的bean,大家都对问题产生的原因感到奇怪,也尝试了各种不同的处理方式,然而都没有效果。无奈之下,我们通过将整个XML文件改写为Java注解声明的形式,才最终解决了问题。相关代码如下所示:


<!-- 项目中一个原有的bean声明 -->
<bean id="myHsfClient" class="com.taobao.hsf.app.spring.util.HSFSpringConsumerBean" init-method="init">
    <property name="interfaceName">
        <value>com.taobao.custom.MyHsfClient</value>
    </property>
    <!-- version属性值为待解析的配置项占位符 -->
    <property name="version">
        <value>${hsf.client.version}</value>
    </property>
</bean>

<!-- 其余bean声明省略 -->

 


// 改写后的Java注解声明方式
@Configuration
public class MyHsfConfig {

    @HSFConsumer(serviceVersion = "${hsf.client.version}")
    private MyHsfClient myHsfClient;

    // 其余代码省略
}
 

虽然问题得到了解决,但是大家仍旧对这其中的原因不明所以。笔者在事后通过本地调试的方式,找到了问题的原因。这其中涉及到bean定义注册表后置处理、bean工厂后置处理、工厂bean等Spring相关的概念。本文将以上述问题作为切入点,进行分析和展开介绍。

XML配置项解析

为了更好地解答上述问题产生的原因,我们先来看下Spring框架对bean使用的配置项的解析过程。我们知道,Spring会负责对我们在XML文件中声明的bean的创建。不过,对其中的配置项解析,并不是在这个环节发生,而是在其前置环节 —— bean工厂后置处理的过程中发生的。bean工厂(BeanFactory)是Spring的核心组件,除了负责初始化bean的实例,记录单例外,它还维护了各个bean的定义(BeanDefinition)。bean的定义中主要记录了bean的类型、作用域(singleton/prototype)、属性值、构造函数参数值等信息。bean的实例化便是基于bean的定义进行的。而bean工厂的后置处理环节,则可以在bean被创建之前,修改bean的定义,以达到影响最终生成的bean实例的效果。
对XML中配置项的解析工作,Spring是通过PropertySourcesPlaceholderConfigurer这个bean工厂后置处理器(BeanFactoryPostProcessor)完成的。其核心代码如下所示。总体思路比较简单,即遍历bean工厂中的bean定义,对于每个bean的定义,访问其属性值、构造函数参数值等信息,解析其中的配置项占位符(placeholder)。这个环节完成之后,在bean工厂对bean进行初始化之前,bean定义中的配置项占位符就已经被替换为实际的属性值了。

// 处理属性值
protected void doProcessProperties(ConfigurableListableBeanFactory beanFactoryToProcess,
        StringValueResolver valueResolver) {

    BeanDefinitionVisitor visitor = new BeanDefinitionVisitor(valueResolver);

    String[] beanNames = beanFactoryToProcess.getBeanDefinitionNames();
    // 遍历bean工厂中的bean名称集合
    for (String curName : beanNames) {
      // 跳过对自身的处理
        if (!(curName.equals(this.beanName) && beanFactoryToProcess.equals(this.beanFactory))) {
            // 通过bean的名称获取bean的定义
            BeanDefinition bd = beanFactoryToProcess.getBeanDefinition(curName);
            try {
                // 访问bean的定义,解析并替换其中的配置项占位符
                visitor.visitBeanDefinition(bd);
            }
            catch (Exception ex) {
                throw new BeanDefinitionStoreException(bd.getResourceDescription(), curName, ex.getMessage(), ex);
            }
        }
    }

    // 将配置项解析器注册添加至bean工厂,供基于注解的配置项解析处理器使用(后文将详细介绍)
    // New in Spring 3.0: resolve placeholders in embedded values such as annotation attributes.
    beanFactoryToProcess.addEmbeddedValueResolver(valueResolver);
    // 其余代码省略
}
了解了bean工厂后置处理环节后,让我们再往前探究一步,看下bean定义本身是如何被加载到bean工厂中的(这将有助于我们理解文章开头所提到的问题的产生原因)。bean定义主要是在bean定义注册表后置处理环节被加载到bean工厂中的。与我们前面提到的bean工厂后置处理环节类似,该环节也存在相应的处理器(BeanDefinitionRegistryPostProcessor)完成相关工作。
其中典型的如ConfigurationClassPostProcessor。以Spring Boot场景为例,简单来说,该bean定义注册表后置处理器会从包含了@SpringBootApplication注解的启动引导类开始,根据其组合注解@ComponentScan,扫描被@Component,或者组合了@Component的注解(如@Configuration、@Service、@Repository等)标注的类,将这些配置类(注1)的bean定义注册至bean工厂。同时,处理器还会根据组合注解@EnableAutoConfiguration,获取Spring Boot中的自动配置类。在这之后,ConfigurationClassPostProcessor会尝试解析各个配置类中包含的@Bean、@ImportResource等注解,将对应的bean定义也注册到bean工厂中。
最后,对于配置项本身来说,Spring的环境抽象(Environment)会拉取并聚合JVM系统属性、操作系统环境变量、应用属性配置文件等多个属性源的数据(注2),以供bean工厂中的bean定义或者bean实例使用。如前面提到的PropertySourcesPlaceholderConfigurer处理器,便是从Spring环境中获取bean定义中的配置项占位符所对应的属性值,并将其替换的。上文通过倒序的方式介绍了配置项解析的相关环节,下面我们用顺序表示的流程图作结,以便读者更好地理解。

问题原因分析

现在,我们可以对文章开头提到的问题作进一步分析了。仔细查看我们所引入的XML文件可以发现,其中包含一个类型为MapperScannerConfigurer的bean声明。Spring借助该类完成对标注有@Mapper注解的MyBatis映射接口的扫描。MapperScannerConfigurer实现了BeanDefinitionRegistryPostProcessor接口,是一个bean定义注册表后置处理器。它对映射接口的扫描及其对应的bean定义的注册,便是在该环节进行的。
前面我们提到,ConfigurationClassPostProcessor这个bean定义注册表后置处理器会扫描并加载@Configuration和@ImportResource注解相关的bean定义。我们所引入的XML文件中的bean的定义,便是通过这个动作被注册到bean工厂中的(见上文MyDataSourceConfiguration配置类)。在ConfigurationClassPostProcessor完成其扫描及加载工作后,由于有新的bean定义被注册,Spring会再次尝试从bean工厂中找出并初始化其他的bean定义注册表后置处理器,以触发它们的处理动作。MapperScannerConfigurer便是在此时被实例化并触发的。
观察问题背景介绍章节中的相关代码可以发现,MapperScannerConfigurer的bean实例(thirdPartyMapperScannerConfigurer)间接依赖了我们通过@Bean注解在配置类中声明的数据源bean实例(myDataSource)。因此,在本文案例中,Spring在创建MapperScannerConfigurer实例时,会首先对数据源bean进行初始化。而对于通过@Bean注解声明的bean,Spring是通过反射调用注解所在的工厂方法(factory method),完成bean的实例化的。我们的数据源myDataSource的实例化,便是通过反射调用其工厂方法createMyDataSource完成的。由于该方法包含了一个类型为Environment入参,Spring需要遍历bean工厂中的bean定义,找到并创建匹配的bean,作为反射调用时的方法传参。
而问题恰恰就出现在这里的参数匹配环节。Spring在进行方法入参匹配时,会首先调用getBeanNamesForType方法,将符合参数类型的bean的名称找出来,然后依据一定的策略(注3)将bean进行实例化,作为方法入参使用。对于普通的bean来说,Spring只需要依据bean定义中包含的bean类型信息,与参数类型作匹配即可;而对于另一类较为特殊的工厂bean(FactoryBean)来说,其类型推断方式就会更加复杂些。下文将会展开介绍工厂bean的概念和案例,对此不太熟悉的读者,这里只需要了解,工厂bean的作用是负责产生某个我们最终实际需要使用的bean。因此,在进行参数匹配时,Spring关心的是这个最终产生的bean的类型,而不是工厂bean本身的类型。
在判断工厂bean实际输出的bean的类型时(注4),Spring首先会尝试根据工厂bean定义中的某些元数据进行类型推断;其次会尝试对工厂bean进行一次简单创建后,通过其getObjectType方法获取目标bean的类型。如果前两种尝试都失败了,则会使用兜底逻辑 —— 对工厂bean进行正式创建后,再通过getObjectType获取类型信息。这里的「正式创建」,我们可以理解为Spring完成了工厂bean的实例化、属性字段的赋值、单例信息的记录等;而「简单创建」仅仅指工厂bean的实例化,不包括后续的字段初始化等动作。
而我们在上文提到的myHsfClient,便是被声明为了一个类型为HSFSpringConsumerBean的工厂bean。Spring在对createMyDataSource的方法入参进行类型匹配时,由于前述的前两种类型推断方式都没有成功(其具体原因将在后文工厂bean小节中介绍),导致该工厂bean最终被「提前」正式创建了出来。读者可能已经发现,此时Spring正处在bean定义注册表后置处理环节。而我们在XML配置项解析章节中提到的对bean定义中的配置项占位符的解析替换,则是在该环节之后的bean工厂后置处理环节进行的 —— 这就是导致myHsfClient这个工厂bean中的配置项没有被正常解析的原因。整体方法调用关系如下图所示:
至此可能读者会有疑问:难道我们的项目中之前没有对@Mapper映射器接口的扫描动作吗?答案是有扫描动作,不过是通过MapperScannerRegistrar这个bean定义注册器触发的。而由于其与我们通过XML所引入的MapperScannerConfigurer的一些细微区别,使得项目中原先不存在工厂bean被提前创建的问题。由于篇幅所限,这里不再对MapperScannerRegistrar作展开介绍。
知道了问题背后的原因后,寻找对应的解法也就相对简单了。对于文中案例,一方面,我们可以看到,由于thirdPartyMapperScannerConfigurer依赖了SqlSessionFactoryBean实例(这就是我们刚刚说的「细微区别」所在),导致其间接依赖了myDataSource。而考察源码可以发现,其实MapperScannerConfigurer只需要SqlSessionFactory的bean名称(sqlSessionFactoryBeanName)作为输入即可,因此我们可以把XML中相关的depends-on声明去除。另一方面,由于createMyDataSource方法入参是Spring环境抽象,我们可以改由通过使配置类实现EnvironmentAware接口的方式,获得应用上下文中的Environment实例。这两种方法都能解决我们的工厂bean被提前创建的问题。
在更一般化的场景中,如果在Spring启动的早期阶段,对某个bean的依赖注入无法避免,我们可以使相关的类实现ApplicationContextAware接口,尝试通过应用上下文(ApplicationContext)的getBean方法获取我们想要的对象。不过需要注意的是,getBean方法存在两类版本:根据bean名称获取实例,或是根据指定类型获取实例;而如果我们选择根据指定类型获取实例,则仍旧会触发上文提到的类型匹配机制,导致某些无法通过正常方式进行类型推断的工厂bean被提前创建出来。最后,对于前文提到的,在使用注解形式改写myHsfClient的bean声明后,问题得到解决的原因,我们将在后文分析介绍。

一些引申扩展

经过上文让人感觉有些绕的分析,我们可以看到,文章开头所提到的问题的本质是,某些bean被Spring提前正式创建了出来,导致其bean声明中的配置项占位符没有来得及被解析和替换。这其中涉及到不少概念,诸如bean定义注册表后置处理、bean工厂后置处理、工厂bean等。由于我们在日常开发中一般接触得不多,读者对它们的理解可能还比较模糊,下文将尝试结合实际案例,进行一些引申和扩展介绍。

 

bean定义注册表后置处理

我们在前文中已经介绍了ConfigurationClassPostProcessor和MapperScannerConfigurer这两个bean定义注册表后置处理器。这类处理器的主要作用便是扫描并向bean工厂中注册bean定义。其中,ConfigurationClassPostProcessor负责扫描配置类,处理其包含的注解,并将相关的bean定义注册至bean工厂中。随后,对于这些新增的bean定义,如果其中又包含了其他的bean定义注册表后置处理器,Spring会将它们实例化,并触发它们的处理动作(注5),继续注册可能被发现的新的bean定义……如此循环往复,直到所有该类型的处理器都被触发,完成bean定义的注册为止。如以下代码所示:
public static void invokeBeanFactoryPostProcessors(
        ConfigurableListableBeanFactory beanFactory, List<BeanFactoryPostProcessor> beanFactoryPostProcessors) {

    // 部分代码省略
    
    // Finally, invoke all other BeanDefinitionRegistryPostProcessors until no further ones appear.
    boolean reiterate = true;
    while (reiterate) {
        reiterate = false;
        // 从bean工厂中找出bean定义注册表后置处理器
        postProcessorNames = beanFactory.getBeanNamesForType(BeanDefinitionRegistryPostProcessor.class, true, false);
        for (String ppName : postProcessorNames) {
            // 如果当前处理器尚未被触发过
            if (!processedBeans.contains(ppName)) {
                // 初始化处理器,并加入到本次需要触发的处理器集合中
                currentRegistryProcessors.add(beanFactory.getBean(ppName, BeanDefinitionRegistryPostProcessor.class));
                // 标记处理器为已被处理
                processedBeans.add(ppName);
                // 继续循环,因为当前集合中的处理器被触发后,可能会引入新的bean定义,其中可能包含新的bean定义注册表后置处理器需要被触发
                reiterate = true;
            }
        }
        sortPostProcessors(currentRegistryProcessors, beanFactory);
        registryProcessors.addAll(currentRegistryProcessors);
        // 触发集合中的处理器的bean定义注册表后置处理动作
        // * 本文案例中,我们在第三方XML文件中引入的MapperScannerConfigurer,便是在此时被触发的
        invokeBeanDefinitionRegistryPostProcessors(currentRegistryProcessors, registry);
        currentRegistryProcessors.clear();
    }
    
}
回到我们的问题案例,MapperScannerConfigurer便是在上述环节被创建出来并触发的。这里,细心的读者可能会有疑问:如果我们在使用XML声明这个Mybatis的处理器时,对其中的某些属性也使用了配置项占位符,那么Spring在创建它时,是否也会遇到同样的解析问题?MapperScannerConfigurer的作者显然是考虑到了这一点 —— 处理器被触发后,支持首先尝试对它的属性字段进行配置项的解析和替换。其具体的实现方式,是构造一个新的bean工厂,将自身的bean定义注册其中,然后借助PropertySourcesPlaceholderConfigurer等处理器,对这个bean工厂执行配置项的后置处理操作;最后,用bean定义中的被解析后的属性值,替换自身实例中原有的属性值。这在一定程度上相当于模拟了Spring的bean工厂后置处理环节。其具体代码如下:
/*
* BeanDefinitionRegistries are called early in application startup, before
* BeanFactoryPostProcessors. This means that PropertyResourceConfigurers will not have been
* loaded and any property substitution of this class' properties will fail. To avoid this, find
* any PropertyResourceConfigurers defined in the context and run them on this class' bean
* definition. Then update the values.
*/
// 上面这段英文注释体现了作者的考虑,即文中描述的情况
private void processPropertyPlaceHolders() {
    // 获取配置项处理器实例,即PropertySourcesPlaceholderConfigurer处理器
  Map<String, PropertyResourceConfigurer> prcs = applicationContext.getBeansOfType(PropertyResourceConfigurer.class);

    if (!prcs.isEmpty() && applicationContext instanceof ConfigurableApplicationContext) {
        BeanDefinition mapperScannerBean = ((ConfigurableApplicationContext) applicationContext)
          .getBeanFactory().getBeanDefinition(beanName);
        
        // 构造一个新的bean工厂
        DefaultListableBeanFactory factory = new DefaultListableBeanFactory();
        // 将自身的bean定义注册到这个bean工厂中
        factory.registerBeanDefinition(beanName, mapperScannerBean);
        // * 对这个bean工厂执行配置项后置处理操作
        for (PropertyResourceConfigurer prc : prcs.values()) {
          prc.postProcessBeanFactory(factory);
        }
        
        PropertyValues values = mapperScannerBean.getPropertyValues();
        // 使用被解析处理过的值更新原有的值
        this.basePackage = updatePropertyValue("basePackage", values);
        this.sqlSessionFactoryBeanName = updatePropertyValue("sqlSessionFactoryBeanName", values);
        this.sqlSessionTemplateBeanName = updatePropertyValue("sqlSessionTemplateBeanName", values);
    }
}
最后,值得一提的是,对于ConfigurationClassPostProcessor的bean定义本身,则是在Spring应用上下文(ApplicationContext)初始化的过程中,通过硬编码的形式被注册到bean工厂中的(注6)。这里同时被注册的还有诸如AutowiredAnnotationBeanPostProcessor等bean后置处理器,我们将在后文对此作相应介绍。

 

bean工厂后置处理

当bean定义注册表后置处理环节完成后,基本上(注7)所有的bean定义都已经被注册至bean工厂中了。随后,Spring会找出所有的bean工厂后置处理器,按照一定的顺序实例化并触发它们的处理动作(优先执行实现了PriorityOrdered接口的,其次执行实现了Ordered接口的,最后执行没有实现前两个接口的)。这类处理器一般会遍历bean工厂中所有的bean定义,执行一些特定的操作。我们在前文提到的PropertySourcesPlaceholderConfigurer这个bean工厂后置处理器,便是在此时被触发的。而在这个所有bean定义都已经准备就绪的阶段,统一进行配置项占位符的解析和替换,其时机总体上也是恰当合理的。
其他的比较典型的Spring内置bean工厂后置处理器还有ConfigurationBeanFactoryMetaData。这个处理器执行的动作比较简单:它会遍历bean工厂中的bean定义,记录其中的工厂方法等元数据信息。其核心代码如下所示。而这份记录的作用,我们将在后文说明。
public class ConfigurationBeanFactoryMetaData implements BeanFactoryPostProcessor {
    
    private Map<String, MetaData> beans = new HashMap<String, MetaData>();
    
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
        this.beanFactory = beanFactory;
        // 遍历bean工厂中的bean定义
        for (String name : beanFactory.getBeanDefinitionNames()) {
            BeanDefinition definition = beanFactory.getBeanDefinition(name);
            String method = definition.getFactoryMethodName();
            String bean = definition.getFactoryBeanName();
            // 如果存在工厂方法元数据(如通过@Bean注解声明的bean),则将相关信息记录下来
            if (method != null && bean != null) {
                this.beans.put(name, new MetaData(bean, method));
            }
        }
    }
}
最后,我们来看另一个和我们的XML配置项解析问题相关的处理器。在问题背景介绍章节中我们提到,当把myHsfClient的bean声明改写为由@HSFConsumer注解修饰的形式后,问题得到了解决。而这背后则是HsfConsumerPostProcessor这个bean工厂后置处理器在发挥作用:对于每一个bean定义,如果它的类属性字段上存在@HSFConsumer注解,处理器会动态生成并注册一个类型为HSFSpringConsumerBean的工厂bean定义。虽然由于PropertySourcesPlaceholderConfigurer处理器实现了PriorityOrdered接口,在此之前已经被优先执行过了,但是HsfConsumerPostProcessor考虑到了这一点 —— 在生成工厂bean定义的过程中,会主动尝试解析相关属性的配置项占位符,因此规避了我们在使用XML方式进行工厂bean声明时遇到的问题。

 

工厂bean

前面我们提到,HSFSpringConsumerBean是一个工厂bean。不仅如此,我们详细讨论的Mybatis的MapperScannerConfigurer处理器,对于其基于@Mapper注解扫描到的映射接口,也会将其bean定义改写为MapperFactoryBean这个工厂bean类型。此外,在Spring中,用于创建Mybatis的SqlSession对象的SqlSessionFactory,也是由一个名为SqlSessionFactoryBean的工厂bean生成的。那么,什么是工厂bean,它的作用又是什么呢?
工厂bean,即FactoryBean,其基于工厂模式,创建我们最终需要的bean实例。根据Spring文档中的介绍(注8),如果某个bean的初始化逻辑较为复杂,不适合使用XML的方式表达,那么我们可以通过使用工厂bean,以Java语言的方式完成目标bean的初始化。工厂bean的概念早在Spring 0.9版本(注9)就已经被引入,在Spring框架中的使用是比较普遍的,至今为止仅其自带的实现就有50多个。下面我们就文中的案例展开介绍。

// MyBatis配置文件路径。配置文件包含数据源、映射器等信息
String resource = "org/mybatis/example/mybatis-config.xml";
// 创建配置文件输入流
InputStream inputStream = Resources.getResourceAsStream(resource);
// 创建SqlSessionFactory实例
SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream);
// 创建SqlSession实例
try (SqlSession session = sqlSessionFactory.openSession()) {
  // 获取BlogMapper映射器
    BlogMapper mapper = session.getMapper(BlogMapper.class);
    // 执行查询语句
    Blog blog = mapper.selectBlog(101);
}
在介绍Mybatis与Spring整合时使用的两个工厂bean之前,我们先来看下相关功能单纯基于Mybatis本身实现时的代码。代码片段摘自Mybatis官网,如上所示。可以看到,其中SqlSessionFactory实例是由SqlSessionFactoryBuilder创建的;而用于执行查询语句的映射器实例,则是由SqlSession实例的getMapper方法创建的。与之相对的,如果阅读源码可以发现,在Mybatis-Spring中,用于创建SqlSessionFactory实例的SqlSessionFactoryBean和映射器实例的MapperFactoryBean这两个工厂bean,在一定程度上可以看作是对上述代码封装和扩展。

<bean id="myInputStream" class="org.apache.ibatis.io.Resources"
      factory-method="getResourceAsStream">
    <constructor-arg value="org/mybatis/example/mybatis-config.xml"/>
</bean>

<bean id="mySqlSessionFactoryBuilder" class="org.apache.ibatis.session.SqlSessionFactoryBuilder"/>

<bean id="mySqlSessionFactory" class="org.apache.ibatis.session.SqlSessionFactory"
      factory-bean="mySqlSessionFactoryBuilder"
      factory-method="build">
    <constructor-arg ref="myInputStream"/>
</bean>
可以看到,虽然借助如上所示的factory-bean和factory-method标签属性,我们也能通过XML完成对SqlSessionFactory的声明,但这种通过XML刻画bean初始化过程的方式,与我们在问题背景介绍章节看到的基于工厂bean的声明方式相比,不免显得有些繁琐了。不过,随着Spring 3.0带来的基于@Configuration的Java注解配置特性,工厂bean在这方面的优势也变得不再那么明显了。

public class MapperFactoryBean<T> extends SqlSessionDaoSupport implements FactoryBean<T> {

    // 映射器接口类型
    private Class<T> mapperInterface;

    // 通过该方法获取我们实际需要的映射器实例
    @Override
    public T getObject() throws Exception {
        return getSqlSession().getMapper(this.mapperInterface);
    }

    // 获取实际的bean的类型,即映射器接口类型
    @Override
    public Class<T> getObjectType() {
      return this.mapperInterface;
    }
    
}
不过,当我们考察如上MapperFactoryBean的源码时,会发现它的bean初始化逻辑很简单,与单纯基于MyBatis的代码实现如出一辙。其中仅有的不同是,这里getMapper方法的映射器类型入参,使用的是工厂bean中的mapperInterface属性。前面我们提到,MapperScannerConfigurer在扫描被@Mapper注解标注的映射器接口时,会为每个接口生成一个对应的bean定义,并将bean定义的类型属性改写为工厂bean类型。而对于bean定义中mapperInterface属性的设置,也是在此时完成的(属性的值即为映射器接口的全限定名)。随后,在bean的实例化环节,Spring便可以基于这些bean定义,为每个映射器接口生成一个对应的工厂bean,以此服务于我们开发中常用的映射器实例依赖注入场景。对此,如果通过Java注解配置或是XML声明的方式实现,则会显得有些大费周章 —— 对于每一个Mybatis映射器接口,我们都需要作一次对应的声明;而如果一个项目中包含数十个映射器接口(这个量级在中大型项目中应属常见),则需要做数十次大同小异的声明。
对于HSFSpringConsumerBean这个工厂bean来说,其作用也是类似。这类bean注入方式的共性是:基于注解(或接口)扫描以及一些相关的配置信息,为每个被标注的接口生成一个对应的工厂bean;而当工厂bean通过getObject方法输出我们最终需要的bean时,往往是基于配置信息为接口生成一个动态代理,供实际使用。这种做法常见于Spring与其他框架集成的场景。就我们文中分析的例子而言,在数据库持久化领域,除了Mybatis外,Hibernate借助JpaRepositoryFactoryBean这个工厂bean生成其Repository接口的实例;在远程调用领域,除了HSF外,Spring Cloud中的Feign通过FeignClientFactoryBean为标注有@FeignClient注解的客户端接口生成动态代理。由于篇幅所限,这里仅以MyBatis为例,展示其类结构关系(见下图)。对于其他的案例,我们不再一一展开分析,感兴趣的读者可以阅读相关源码作进一步了解。
回到我们文章中探讨的配置项解析问题,可以看到,虽然工厂bean能为Spring与其他框架整合提供很多便利,但如果使用不慎,则可能导致一些隐蔽的问题。其实,在2015年,MyBatis的MapperFactoryBean也遇到了类似的与类型推断相关的问题(详见github - mybatis-spring issue #58及pull request #59),而社区对此的解决方式是:利用Spring对bean进行实例化时,会首先尝试匹配有参构造函数的特性,在MapperFactoryBean中新增一个以映射器类型为入参的构造函数;并在处理工厂bean定义的阶段,将映射器类型作为构造函数参数,放入bean定义中(如下图所示)。如此,在前文提到的「简单创建」后,Spring便可以通过调用getObjectType方法获取到当前MapperFactoryBean实例所代表的映射器接口类型了。
最后,回到本次问题的关键点之一:HSFSpringConsumerBean。在使用XML声明的方式时,虽然我们在工厂bean的interfaceName字段指定了客户端接口类型,但Spring在尝试对其进行「简单创建」以做类型推断时,并不会为实例中的属性字段赋值。这导致我们无法通过调用该实例的getObjectType方法得到它所代表的客户端接口类型,并最终导致该工厂bean被「正式创建」了出来。虽然通过@HSFConsumer注解声明的形式,我们得以规避了配置项解析问题,但HSF作者可以考虑参考MapperFactoryBean的方式,增加一个以客户端接口类型为入参的构造函数,来更好地兼容基于XML的声明方式。

基于注解的配置项解析

上文主要围绕基于XML声明的配置项解析进行了分析探讨,其实,自Spring引入基于Java注解的bean声明能力以来,我们使用得更多的是基于注解的配置项解析特性。而对此特性的支持主要是通过Spring的bean后置处理器(BeanPostProcessor)完成的。绝大部分bean的后置处理是在bean的创建环节被触发的:bean工厂首先对bean进行实例化,然后使用bean后置处理器对它们进行相应的处理操作。下面我们进行简单的介绍。
前面我们提到,Spring会以硬编码的形式将AutowiredAnnotationBeanPostProcessor这个bean后置处理器注册到bean工厂中。从字面上看,这个处理器是负责@Autowired注解的,其实,@Value注解也在它的处理范围之内。处理器会在bean实例化后的属性赋值步骤(注10)被触发,对@Value注解中的配置项占位符进行解析,并将属性值赋给被注解标注的字段。而其使用的配置项解析器,其中之一就是通过PropertySourcesPlaceholderConfigurer这个bean工厂后置处理器添加的(详见XML配置项解析章节)。
另一个我们常见的配置项相关的注解是@ConfigurationProperties。该注解由ConfigurationPropertiesBindingPostProcessor这个bean后置处理器处理,处理动作在bean实例化后的初始化步骤(注11)被触发。除了我们熟知的作用于类的使用方式外,@ConfigurationProperties还可以作用于被@Bean注解标注的方法 —— 这主要是针对我们无法直接将注解加在第三方外部类上的情况。而这里对于方法级别的注解解析,处理器便是借助我们之前提到的ConfigurationBeanFactoryMetaData的工厂方法记录完成的(详见bean工厂后置处理小节)。具体代码如下所示:

@Override
public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
    ConfigurationProperties annotation = AnnotationUtils.findAnnotation(bean.getClass(),
            ConfigurationProperties.class);
    if (annotation != null) {
        postProcessBeforeInitialization(bean, beanName, annotation);
    }
    // 处理方法级别的@ConfigurationProperties注解
    // 这里的this.beans即为ConfigurationBeanFactoryMetaData实例
    annotation = this.beans.findFactoryAnnotation(beanName, ConfigurationProperties.class);
    if (annotation != null) {
        postProcessBeforeInitialization(bean, beanName, annotation);
    }
    return bean;
}

思考与总结

我们可以看到,随着Spring从基于XML的bean声明到基于Java注解的bean声明能力的演化,对配置项的解析方式也在发生着变化。其中牵涉到bean工厂后置处理、bean后置处理等环节,而它们彼此之间又存在一定的关联。同时,如果某些bean(如工厂bean)由于某些原因,在Spring启动的早期阶段(如bean定义注册表后置处理环节)被提前创建了出来,则可能导致其中的配置项解析失败。对此,我们一方面可以尝试寻找规避手段,另一方面也可以从该bean本身的设计探究原因。
Spring后置处理器
处理器类型
说明
ConfigurationClassPostProcessor
bean定义注册表后置处理器
在Spring Boot中,从包含了@SpringBootApplication注解的引导类开始,扫描并注册bean定义至bean工厂。在本文案例中,MapperScannerConfigurer的bean定义便是在此时被注册的。
MapperScannerConfigurer
bean定义注册表后置处理器
扫描@Mapper注解标注的映射器接口,生成并注册对应的MapperFactoryBean工厂bean定义。支持使用PropertySourcesPlaceholderConfigurer等处理器对自身的属性字段进行配置项解析。
PropertySourcesPlaceholderConfigurer
bean工厂后置处理器
遍历bean定义,解析其中的配置项占位符。
ConfigurationBeanFactoryMetaData
bean工厂后置处理器
遍历bean定义,记录工厂方法等信息。
HsfConsumerPostProcessor
bean工厂后置处理器
遍历bean定义,对于被@HsfConsumer注解标注的属性字段,生成并注册对应的HSFSpringConsumerBean工厂bean定义。
AutowiredAnnotationBeanPostProcessor
bean后置处理器
解析@Value注解中的配置项占位符。解析器之一由PropertySourcesPlaceholderConfigurer提供。
ConfigurationPropertiesBindingPostProcessor
bean后置处理器
解析@ConfigurationProperties注解中的配置项。对@Bean方法级别的注解解析借助ConfigurationBeanFactoryMetaData中的bean工厂方法记录完成。
为了方便读者理解,以上表格整理了文中提到的各类Spring后置处理器,以及它们彼此的关联。可以看到,Spring框架在给我们提供了很多开发便利的同时,其整体的设计还是较为复杂的。在日常开发中,我们可能时不时会遇到一些「疑难杂症」,而此时对框架的深入理解能帮助我们高效地解决问题。此外,善用对Spring代码的调试,也能帮助我们在纷繁的思路或线索中定位到问题原因。最后,由于写作时间仓促,且Spring不同版本间可能存在一定的行为差异,文中如有错漏之处还请读者包涵指正。

注释:

  1. 除了被@Configuration注解标注的类外,被@Component等注解标注的类也被Spring视为配置类,不过是轻量级(lite)配置类,参见《Spring Core Technologies》1.12章节 - Java-based Container Configuration。

  2. 参见《Spring实战》6.1.1小节 - 理解Spring的环境抽象。

  3. 对于匹配到多个bean的情况,会优先取包含@Primary注解或者优先级高的bean,如果无法判断,则会抛出NoUniqueBeanDefinitionException异常;对于没有匹配到bean的情况,抛出NoSuchBeanDefinitionException异常。

  4. 具体代码详见AbstractAutowireCapableBeanFactory#getTypeForFactoryBean方法。

  5. 即调用BeanDefinitionRegistryPostProcessor接口中定义的postProcessBeanDefinitionRegistry方法。

  6. 具体代码详见AnnotationConfigUtils#registerAnnotationConfigProcessors方法。

  7. 某些bean工厂后置处理器也会向bean工厂中添加新的bean定义,比如我们后文将讨论的HsfConsumerPostProcessor处理器。

  8. 参见《Spring Core Technologies》1.8.3小节 - Customizing Instantiation Logic with a FactoryBean:If you have complex initialization code that is better expressed in Java as opposed to a (potentially) verbose amount of XML, you can create your own FactoryBean, write the complex initialization inside that class, and then plug your custom FactoryBean into the container.

  9. 在FactoryBean的代码注释中,我们可以看到,该类是在2003年3月份被创建的。而根据《History of Spring Framework and Spring Boot》一文,Spring 0.9的发布时间为2003年6月。

  10. 具体代码详见AbstractAutowireCapableBeanFactory#populateBean方法。

  11. 具体代码详见AbstractAutowireCapableBeanFactory#initializeBean方法。

参考资料:

  1. 《Spring Core Technologies》:https://docs.spring.io/spring-framework/docs/current/reference/html/core.html

  2. 《Spring实战》:https://book.douban.com/subject/36142064/

  3. 《MyBatis 3源码深度解析》:https://book.douban.com/subject/34836563/

  4. 《History of Spring Framework and Spring Boot》:https://www.quickprogrammingtips.com/spring-boot/history-of-spring-framework-and-spring-boot.html

  5. 《SpringCloud、Nginx高并发核心编程》:https://book.douban.com/subject/35396578/

  6. mybatis - getting started:https://mybatis.org/mybatis-3/getting-started.html

  7. github - mybatis-spring issue #58:https://github.com/mybatis/spring/issues/58

  8. github - mybatis-spring pull request #59:https://github.com/mybatis/spring/pull/59
 
作者|杨天逸(在田)

热门相关:骑士归来   法医娇宠,扑倒傲娇王爷   豪门重生盛世闲女   惊世毒妃:轻狂大小姐   法医娇宠,扑倒傲娇王爷