shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tauren Mills <>
Subject Re: SessionManager API modification
Date Wed, 19 May 2010 02:34:05 GMT

I just did an svn update, mvn clean, mvn install of your branch, and
so far all looks good. No more exceptions or odd behavior.  Thanks so
much! I'll let you know if I run into anything else.


On Tue, May 18, 2010 at 7:03 PM, Les Hazlewood <> wrote:
> I've implemented the fix for SHIRO-164 into the branch.  It looks like
> I'm going to have to commit this to trunk, however, all tests pass and
> real-world applications tested against it are doing well.
> Barring any user-reported issues, I think we're all done with code
> (maybe some JavaDoc, but no programming).  I'll bump the release
> thread next to see what our next steps are.
> On Mon, May 17, 2010 at 5:24 PM, Les Hazlewood <> wrote:
>> 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