I completely agree with removing. Kalle
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 >
