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 Wed, 19 May 2010 02:42:58 GMT
Hi Tauren,

Can you please verify the trunk now that the merge has been completed?



On Tue, May 18, 2010 at 7:34 PM, Tauren Mills <> wrote:
> Les,
> 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.
> Tauren
> 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 <>
>>>> 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