The new changes work here too ( all my tests pass anyway) I have one question though. My base test class was setting mock requests and responses. Which I am assuming is no longer needed now that the WebSessionManager doesn't require them..
WebUtils.bind( mockRequest ); WebUtils.bind( mockResponse ); Is there an equivalent? If so is there any reason I would want to set them for a test. Thanks On Wed, May 19, 2010 at 2:17 AM, Les Hazlewood <lhazlew...@apache.org>wrote: > 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 > >>>>>> > >>>>> > >>>> > >>> > >> > > >
