shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "gembin (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SHIRO-434) Improve design of ShiroFilterFactoryBean
Date Wed, 03 Dec 2014 07:23:12 GMT

    [ https://issues.apache.org/jira/browse/SHIRO-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14232707#comment-14232707
] 

gembin commented on SHIRO-434:
------------------------------

No plan to fix?  or any workaround? thanks

> 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 was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message