I completely agree with removing.


On Tue, Dec 22, 2009 at 10:13 AM, Les Hazlewood <lhazlew...@apache.org> wrote:
> Hi all,
> There is something in the Shiro codebase that I have never really
> liked, but added for convenience, especially for easy Spring
> configuration.
> We have a lot of pass through methods that merely take an instance and
> funnel it down to a nested component so it can be set on that nested
> component.  This bloats the core implementations considerably and adds
> a lot of general 'noise' in my opinion.
> Some examples:
> - DefaultSecurityManager#setSessionFactory.  This checks to see if the
> sessionManager 'instanceof' SessionFactoryAware and if so, calls
> sessionManager.setSessionFactory.
> - DefaultSecurityManager#setRememberMeEncryptionCipherKeyHex - gets
> the RememberMeManager, checks to see if it is an 'instanceof'
> AbstractRememberMeManager' then calls
> ((AbstractRememberMeManager)rememberMeManager).setCipherKeyHex which
> itself does something similar.
> Consider these two respective config settings in the alternative .ini
> or groovy builder syntax:
> securityManager.sessionManager.sessionFactory = $mySessionFactory
> securityManager.rememberMeManager.cipher.hexKey = blahblahblah
> This is so much easier to maintain in code.
> I'd like to remove all of these (what I consider ugly) 'pass through'
> configuration methods that exist for primarily Spring's benefit.  If
> we still need them, I'd much rather put them in a Builder object that
> could then be used by, say, a Spring FactoryBean to build the final
> object graph.
> This way, we accomplish the simplicity of 'single property setters' if
> desired, but the core code base and architecture does not suffer
> because of it.
> Any objections to me removing these weird pass-through setters prior
> to 1.0 as long as we maintain simple configuration via an alternative
> mechanism?
> - Les

Reply via email to