Removing convenience methods and *Aware interfaces in Shiro Core

[Les Hazlewood <lh...@apache.org>]

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

Re: Removing convenience methods and *Aware interfaces in Shiro Core

[Kalle Korhonen <ka...@gmail.com>]

I completely agree with removing.

Kalle


On Tue, Dec 22, 2009 at 10:13 AM, Les Hazlewood <lh...@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
>