Oliver Gierke created SHIRO-434:
-----------------------------------
Summary: Improve design of ShiroFilterFactoryBean
Key: SHIRO-434
URL: https://issues.apache.org/jira/browse/SHIRO-434
Project: Shiro
Issue Type: Improvement
Components: Integration: Spring
Affects Versions: 1.2.1
Reporter: Oliver Gierke
Assignee: Les Hazlewood
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
