shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <>
Subject SessionManager API modification
Date Mon, 17 May 2010 22:15:23 GMT
I've got one thing left to address before resolving SHIRO-162 [1]:

Up to this point, the work to remove lots of cross-referenced
constants and the ThreadContext usages has gone very well.  However,
it has become readily apparent of the architectural flaws of the
existing SessionManager interface:

All of the methods except for 'start' mandate that all session data
can be resolved based on a session ID.  However, this is definitely
not true for ServletContainer environments.

So, the web-based SecurityManager and SessionManager implementations
still need to resort to brittle ThreadContext usages with keyed
constants to pull ServletRequest/ServletResponse pairs off of the
thread.  It is less than ideal and feels quite hacky in places.

It makes sense to me to move the ID-based methods to a sub-interface,
maybe something like NativeSessionManager to account for this.
Without this, the Web SecurityManager/SessionManager implementations
will remain complex and somewhat difficult to trace.

Since we're still waiting for Infra to enable something for Kalle
before we finish our last issue, what do you guys think of me doing
this today?  I already have an implementation plan in place (and most
stuff is already done, I just don't want to commit without the dev
team being ok with this), and it will be complete today (with tests)
if allowed to proceed.  Note that this has no end-user impact on the
Subject or Session API.




View raw message