shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tauren Mills <tau...@tauren.com>
Subject Re: SessionManager API modification
Date Wed, 19 May 2010 05:13:12 GMT
Now using the latest maven snapshot (170) from:
https://repository.apache.org/content/repositories/snapshots/org/apache/shiro/shiro-core/1.0-incubating-SNAPSHOT/

All is looking good...

Tauren


On Tue, May 18, 2010 at 7:42 PM, Les Hazlewood <lhazlewood@apache.org> wrote:
> Hi Tauren,
>
> Can you please verify the trunk now that the merge has been completed?
>
> Thanks,
>
> Les
>
> On Tue, May 18, 2010 at 7:34 PM, Tauren Mills <tauren@tauren.com> 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 <lhazlewood@apache.org> 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 <lhazlewood@apache.org>
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 <lhazlewood@apache.org>
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] https://issues.apache.org/jira/browse/SHIRO-162
>>>>>
>>>>
>>>
>>
>

Mime
View raw message