记录Mybatis的配置之谜

 每个现象背后都有其缘由，越离奇的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，不要百度一下解决方案处理就结束了，而是要深入了解一下背后的机制和原理，希望大家都能够多多探索更加深入的原理，获得更多的知识。