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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 >>>>> >>>> >>> >> >
