You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by "Oliver Gierke (JIRA)" <ji...@apache.org> on 2013/05/04 20:52:16 UTC
[jira] [Updated] (SHIRO-434) Improve design of
ShiroFilterFactoryBean
[ 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