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 >
