Thanks again!
On Tue, May 18, 2010 at 10:13 PM, Tauren Mills <tau...@tauren.com> wrote: > 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 <lhazlew...@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 <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 >>>>>> >>>>> >>>> >>> >> >
