[SHIRO-434] Improve design of ShiroFilterFactoryBean

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 1.2.1
• Component/s: Integration: Spring
• Assignee: Les Hazlewood
• Reporter: Oliver Drotbohm
• Created: 04/May/13 14:54
• Updated: 03/Dec/14 07:22

Description

Currently ShiroFilterFactoryBean implements both BeanPostProcessor as well as FactoryBean. This is unfortunate as BeanPostProcessors are instantiated extremely early in the lifecycle of a Spring Application context. This means, dependencies needed to be wired into the BPP instance (esp. the SecurityManager and it's transitive dependencies) are already looked up at a time when potentially not even all BeanPostProcessors are instantiated. In general, BeanPostProcessors should not have general dependencies on application components as this potentially triggers premature intialization of application components which can cause subtle issues with dependency resolution, other BeanPostProcessors not being applied etc. (see [0] as an example).

Looking at the implementation of ShiroFilterFactoryBean it seems the implementation of the BeanPostProcessor interface can be extracted into a separate class so that it doesn't trigger the initialization of the SecurityManager on BeanPostProcessor instantiation. The BPP instance can then be wired to the factory bean or looked up through the BeanFactory (through implementing BeanFactoryAware). This would delay the initialization of the SecurityManager (which seems to be triggering the transitive dependency lookups) until the FactoryBean implementation is initialized.

[0] https://jira.springsource.org/browse/DATAJPA-335