Hi James, This *might* be a bug - do you have any information on when the ThreadLocal might be replaced and what it is replaced with? Also, is this repeatable at all? I would love to get my hands on a test case that re-creates the issue (even if there is no obvious solution in sight). Repeatability is the key to solving thread-related issues IMO.
Anyway, Shiro has a ThreadState concept that sits on top of the ThreadContext (which masks interaction with a ThreadLocal). The ThreadState will store Shiro's thread state to the ThreadContext at the beginning of a request, but it will replace what might have been there previously at the end of the request. That is, ThreadState works like this: bind() (beginning of the request): - save what might have been on the thread (call ThreadContext.getResources()) - bind the specified Subject and SecurityManager to the thread restore() (end of the request, or in the event of an exception): - remove the ThreadLocal (threadLocal.remove()). This will cause a new Map instance to be created on the next ThreadLocal.get() call. - reinstate what might have been on the thread (call ThreadContext.setResources(previousResources); ) As mentioned, the ThreadLocal.remove() call will remove the original map and cause a new Map to be created as necessary for future ThreadLocal.get() calls. Do you think this is causing you trouble? Perhaps we should call ThreadLocal.get().clear() instead? Please keep us posted if possible. Best, -- Les Hazlewood CTO, Katasoft | http://www.katasoft.com | 888.391.5282 twitter: @lhazlewood | http://twitter.com/lhazlewood katasoft blog: http://www.katasoft.com/blogs/lhazlewood personal blog: http://leshazlewood.com On Tue, Jan 10, 2012 at 4:57 AM, Jamesb <[email protected]> wrote: > (Thanks Alexandr) > Indeed, that's what I thought. I've already done as you outline, and it > looks like it might be a bug as the subsequent calls to ThreadLocal.get() > are getting a different instance and hence throwing the exception above. > That said, it seems that there are loads of instances of people using Shiro > in a similar configuration to mine, so I figure it should be a well-trodden > path (so it follows the likelihood of it being a bug is slim), so I was > hoping to bump this thread to see if someone with more experience of this > area of the codebase could make sense of what I was seeing in my debugger? > > -- > View this message in context: > http://shiro-user.582556.n2.nabble.com/Do-you-have-to-SecurityUtils-setSecurityManager-in-a-web-app-to-use-shiro-tag-library-tp7114798p7171946.html > Sent from the Shiro User mailing list archive at Nabble.com.
