每个现象背后都有其缘由,越离奇的bug越是由不起眼的细节引发,每个bug背后都有框架或代码运行的原理和机制所在,解决bug,不仅仅需要去网上查询,还需要对其背后的原理进行了解和总结。
同事大佬最近在学习并使用Mybatis,他使用Mybatis的MapperScannerConfigurer来进行相关配置,并希望通过yml配置来指定basePackage,mappers等属性。为此,编写了自定义的配置类StarterAutoConfiguration
和自定义属性类TkProperties
,并在初始化MapperScannerConfigurer
时使用TkProperties
中的属性。但是,事与愿违,在初始化MapperScannerConfigurer
时,TkProperties
实例中的属性死活都是未初始化状态。
为此,我们花了大量时间探查缘由,最后不得不询问了另一位大佬,才发现这个离奇问题的背后竟然有着这样的缘由。
我们首先来看一下大佬关于MapperScannerConfigurer
的自定义配置实现。他首先定义了自定义配置类BkStarterAutoConfiguration
,使用@EnableConfigurationProperties
注解将TkProperties
声明为配置属性类。
@Configuration
@EnableConfigurationProperties({TkProperties.class})
@AutoConfigureBefore(MybatisAutoConfiguration.class)
public class BkStarterAutoConfiguration {
@Bean
@ConditionalOnMissingBean
@Order(Ordered.HIGHEST_PRECEDENCE)
public TkProperties tkProperties() {
return new TkProperties();
}
}
下面是TkProperties
的定义,使用@ConfigurationProperties
注解声明了该属性配置的前缀,两个属性名称为basePackage
和mappers
。
@Data
@ConfigurationProperties(prefix = "tk")
public class TkProperties {
private String basePackage;
private String mappers;
}
MapperConfig
是声明并配置MapperScannerConfigurer
实例的配置类,使用被@Bean
注解修饰的mapperScannerConfigurer
方法来初始化,其方法参数为TkProperties
。
@Configuration
public class MapperConfig {
@Bean
public MapperScannerConfigurer mapperScannerConfigurer(TkProperties tkProperties) {
MapperScannerConfigurer mapperScannerConfigurer = new MapperScannerConfigurer();
mapperScannerConfigurer.setSqlSessionFactoryBeanName("sqlSessionFactory");
//使用TkProperties的成员变量来配置mapperScannerConfigurer
mapperScannerConfigurer.setBasePackage(tkProperties.getBasePackage());
Properties properties = new Properties();
properties.setProperty("mappers", tkProperties.getMappers());
mapperScannerConfigurer.setProperties(properties);
return mapperScannerConfigurer;
}
}
yml配置文件如下所示。
---
tk:
basePackage: cn.remcarpediem.mybatis.dao
mappers: cn.remcarpediem.mappers.BaseDao
代码乍看起来一定问题都没有,但是运行时,在初始化MapperScannerConfigurer实例时,TkProperties实例的属性死活就是没有初始化成功。
运行调试图 一定有很多见多识广的读者已经知道这个现象背后的原因。“凶手”就是MapperScannerConfigurer
实现的接口BeanDefinitionRegistryPostProcessor
。具体原因我们还需要慢慢来解释,因为它涉及了Spring Boot的很多原理。
首先,BeanDefinitionRegistryPostProcessor
接口继承了BeanFactoryPostProcessor
接口,大家一般都对BeanFactoryPostProcessor
较为熟悉,它是实例工厂(BeanFactory)的后处理器(PostProcessor),与之类似的还有实例的后处理器(BeanPostProcessor)。BeanFactoryPostProcessor
中只定义了一个方法,其将会在ApplicationContext
内部的BeanFactory
加载完BeanDefinition
后,但是在Bean实例化之前进行。所以通常我们可以通过实现该接口来对实例化之前的BeanDefinition
进行修改。比如说PropertySourcesPlaceholderConfigurer
就实现BeanFactoryPostProcessor
接口,用于处理实例中被@Value
注解修饰的变量,修改其数值。
public interface BeanFactoryPostProcessor {
void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException;
}
而BeanDefinitionRegistryPostProcessor
接口扩展自BeanFactoryPostProcessor
,它是BeanDefinitionRegistry
的后处理器,它可以在BeanFactoryPostProcessor
检测之前注册一些特殊的BeanDefinition
,比如说可以注册用来定义BeanFactoryPostProcessor
的BeanDefintion
,比如说我们之前提到的
MapperScannerConfigurer
和ConfigurationClassPostProcessor
。
public interface BeanDefinitionRegistryPostProcessor extends BeanFactoryPostProcessor {
void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry) throws BeansException;
}
MapperScannerConfigurer
的postProcessBeanDefinitionRegistry
主要用来ClassPathMapperScanner
来扫描Mybatis
的Mapper
。ClassPathMapperScanner
继承了ClassPathBeanDefinitionScanner
,在doScan
方法中获取了basePackage
指定的包路径下的所有Mapper
的BeanDefinition
,然后进行注册。
而BeanPostProcessor
就是Bean实例的后处理器。每个Bean实例在进行初始化前会调用其postProcessBeforeInitialization
方法和初始化之后调用其postProcessAfterInitialization
方法。ConfigurationPropertiesBindingPostProcessor
实现了BeanPostProcessor
接口,用于处理被@ConfigurationProperties
修饰的实例。
public interface BeanPostProcessor {
Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;
Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;
}
我们可以总结一下BeanDefinitionRegistryPostProcessor
,BeanFactoryPostProcessor
和BeanPostProcessor
三个后处理器发挥作用的次序和时机。
由此,我们也能够理解为什么MapperScannerConfigurer
初始化时,TkProperties
还没有初始化,那是因为ConfigurationPropertiesBindingPostProcessor
还没有初始化,并且也没有对TkProperties
进行处理。
遇到问题和bug,不要百度一下解决方案处理就结束了,而是要深入了解一下背后的机制和原理,希望大家都能够多多探索更加深入的原理,获得更多的知识。
网友评论