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 <tau...@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 <lhazlew...@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 <lhazlew...@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 <lhazlew...@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 >>>> >>> >> >
