spring-boot & shiro 集成 - beans 的级联初始化问题

问题背景

• 使用 shiro-spring-boot-web-starter 将 Shiro 集成到 spring-boot 中
• 自定义了一个 FormRealm
  • FormRealm 通过 @Configuration & @Bean 创建.
  • 依赖一个 XxxService, 并通过 @Autowired 注入, XxxService 依赖 EntityManager 和 XxxRepository, 并通过 @Autowired 注入.

问题描述

遇到了各种其怪的问题，比如：

1. 感觉数据源初始化时机提前了很多，甚至导致 DataSource Initializer 执行脚本的时机早于 JPA ddl-auto 的时机，从而导致 table xxx does not exist 之类的错误.
   180123 更新

   // HibernateJpaAutoConfiguration.java
   ...
   @AutoConfigureAfter({ DataSourceAutoConfiguration.class })
   public class HibernateJpaAutoConfiguration
   ...
   

   注意 @AutoConfigureAfter, 说明 JPA ddl-auto 比 DataSource Initializer 执行时机晚是正常的. 如果在@Configuration 类内定义一个 @Autowired 的 EntityManager 会导致 JPA ddl-auto 执行时机早于 DataSource Initializer 执行时机 ?!
2. 配置 liquibase 的时候，因为配置文件的错误导致启动异常，打印出的异常堆栈信息非常奇怪，内因是 liquibase 配置异常没有问题，但最外层的异常信息却是 Shiro 相关 Bean 的创建错误. (异常信息片段如下)

   ...
   org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'shiroEventBusAwareBeanPostProcessor' defined in class path resource 
   nested exception is org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'authorizationAttributeSourceAdvisor' defined in class path resource
   ...
   

3. 如果手动管理 ShiroFilterFactoryBean 的初始化, 即放弃 Shiro 对 ShiroFilterFactoryBean 的自动配置, FormRealm 通过 @Autowired 自动注入的 XxxService 居然会导致 XxxService 中的 @Transactional 失效. 经测试, 注释掉 FormRealm 中对 XxxService 的 @Autowired 注解后, @Transactional 又重新生效.

所以断定, 由于 Shiro 的集成, 或者说由于 Shiro 的错误配置，对整个应用的初始化产生了不小的影响.

Bean 初始化链分析

1. shiro-spring-boot-web-starter#src/main/resources/META-INF/spring.factories

   org.springframework.boot.autoconfigure.EnableAutoConfiguration = \
     org.apache.shiro.spring.config.web.autoconfigure.ShiroWebAutoConfiguration,\
     org.apache.shiro.spring.config.web.autoconfigure.ShiroWebFilterConfiguration
   

2. ShiroWebFilterConfiguration#shiroFilterFactoryBean
3. AbstractShiroWebFilterConfiguration#shiroFilterFactoryBean
   • 重点1: ShiroFilterFactoryBean 是一个 BeanPostProcessor, 而 BeanPostProcessor 的初始化时机要比普通 Bean 早
   • 重点2: 通过 @Autowired 自动注入了一个 SecurityManager, 即必须先初始化 SecurityManager
4. 而 SecurityManager 由 ShiroWebAutoConfiguration#securityManager 创建, 代码如下:

   protected SessionsSecurityManager securityManager(List realms) {
     return super.securityManager(realms);
   }
   

   可以看到, securityManager 依赖所有类型为 Realm 的 Bean, 即必须先初始化类型为 Realm 的 Bean
5. FormRealm 属于 Realm 类型, 所以被提前创建, 从而导致 FormRealm 所依赖的一系列 @Autowired 的 Bean 都被提前创建

总结

ShiroFilterFactoryBean 属于一个 BeanPostProcessor, 它的初始化时机比普通 Bean 要早, 又因为依赖链为 ShiroFilterFactoryBean -> SecurityManager -> FormRealm -> XxxService -> XxxRepository, 依赖链末端甚至依赖 DataSource 的初始化. 所以, Shiro 与 spring-boot 的集成导致了 DataSource 初始化时机过早的问题, 这也是 DataSource Initializer 执行时机 (在集成 Shiro 后) 早于 JPA ddl-auto 执行时机的原因.

另外, 如果手动配置 ShiroFilterFactoryBean, 那么它的初始化, 会带动整个 bean 初始化链, 再进一步提前. 甚至早于某些创建代理相关的后处理器, 比如为 @Transactional 创建代理的后处理器, 从而导致这些被提前初始化的 bean 未被某些后处理器处理就已经完成了初始化, 这就是上面提到的 @Transactional 失效的原因.

最后说一下解决方法, 非常简单, 原理是通过在 FormRealm 中使用 @Lazy 把整个依赖链切断 (把 shiro 相关 bean 的初始化 与 业务相关 bean 的初始化 切断).

# FormRealm.java
...
@Autowired
@Lazy
private XxxService xxxService;
...

补充

手动配置 ShiroFilterFactoryBean 导致依赖链初始化时机再进一步提前的原因

通常来讲, spring boot 自动配置 (auto configuration) 的 bean 其初始化时机要晚于应用配置的 @Bean 的初始化时机, 因为 spring boot 自动配置需要根据应用上下文 (BeanFactory / ApplicationContext) 的状态来决定如何配置, 比如如果用户自己手动定义了一个 ShiroFilterFactoryBean 类型的 bean, 那么自动配置在执行时就不会再初始化一个 ShiroFilterFactoryBean, 再比如如果用户自己手动定义了一个 bean name 为 foo 的 bean, 那么自动配置在执行时就不再初始化一个 Foo 类型的 bean.(可以通过 @ConditionalOnMissingBean 等条件注解设置规约).

再来看, 如果手动配置 ShiroFilterFactoryBean, 那么它的初始化时机会就会早于 spring boot 的自动配置, 又因为它还是一个 BeanPostProcessor, 并且依赖着一些业务相关的 bean, 那么整个依赖链上所有的 bean 其初始化时机就会都早于 spring boot 自动配置的执行时机. 从而导致这些早生儿错过了一些后期护理工作 (后处理).