shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <>
Subject Re: SessionManager API modification
Date Tue, 18 May 2010 00:24:56 GMT
Just a quick note - I'm committing these changes to a branch for peer
review.  If good, we can merge.

- Les

On Mon, May 17, 2010 at 3:15 PM, Les Hazlewood <> wrote:
> 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.
> Thoughts?
> Les
> [1]

View raw message