Hi Will,
There are a few reasons. A big one is this configuration (in INI, but
any other is equally as trivial):
securityManager.cacheManager = $cacheManager
is much nicer than forcing all end users to write code to do this:
securityManager.getSessionManager().getSessionDAO().setCacheManager(manager);
Collection<Realm> realms = securityManager.getRealms();
for( Realm realm : realms ) {
if ( realm instanceof CacheManagerAware) {
((CacheManagerAware)realm).setCacheManager(cacheManager);
}
}
In other words, there are more components other than the
SessionManager/SessionDAO that could use a CacheManager. Knowing how
and when to apply the cache manager can be confusing for many people,
so we encapsulate this to make lives easier.
Also, the ID passing approach exists specifically for encapsulation:
the 'real' session instance never leaves the bounds of the
SessionManager because different EIS data stores manage data, state,
and lifecycles differently; By using a thin delegating proxy, the
SessionManager implementation (and DAO) can manage exactly how
lifecycle events should occur, which can vary across different backing
stores.
But to your point, if the community feels that this can be made more
elegant and should be (and I would argue without sacrificing
flexibility for multiple management implementations), then of course
we can refine this. Subject and Subject.getSession() API end-users
would never know, but of course backing provider implementors would be
affected by such a change (so it would probably have to wait until 2.x
if it was voted favorably).
Finally, we've got an issue to reduce/remove API clutter:
https://issues.apache.org/jira/browse/SHIRO-128
That should help too.
Any other feedback is greatly appreciated! If you have any
suggestions, please feel free to post them here. I look forward to
this type of discussion. :)
HTH,
Les
2010/3/24 Willi Schönborn <[email protected]>:
> Hi folks,
>
> this might be my personal sensation but the api seems to be very verbose.
> There are e.g. a lot of methods there, taking a session id as the first
> parameter.
> I found those methods "all over the place" and it's very obvious
> what they do, they all just delegate the real session.
> What's the advantage of having pure delegate methods everywhere?
> To be specific, what makes
> SecurityManager.setCacheManager(manager);
> better than
> SecurityManager.getSessionManager().setCacheManager(manager);
>
> Thanks in advance,
> Willi
>
