[
https://issues.apache.org/jira/browse/SHIRO-434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oliver Gierke updated SHIRO-434:
--------------------------------
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
was:
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.
> 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.
> [0] https://jira.springsource.org/browse/DATAJPA-335
--
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
