Actually the subject.execute does the thread binding and unbinding automatically, before and after callable execution, respectively. This is to ensure that any SecurityUtils.getSubject() calls that exist during the course of the execution work successfully so you don't have to pollute your API by passing a Subject instance for every method call.
But this is to support a programming model that people often expect and are comfortable with. There is certainly nothing in Shiro that prevents you from managing Subject state yourself, and in fact, in some scenarios (like async/non-blocking scenarios), creating and managing your own Subject instance might be necessary. This is also why those looking closely at the Shiro codebase have noticed that we're trying to reduce touch-points with ThreadLocals as much as possible - to let the application dictate the need (or prevention even) of thread binding behavior. As always, use the right tool for the job - Shiro tries to support both models to ensure that the security API experience is a cohesive one, regardless of your application's particular requirements. Cheers, Les On Mon, Feb 22, 2010 at 4:17 AM, Jason Eacott <[email protected]> wrote: > Actually I think its probably good that you dont need to bind to a thread by > default, even in webapps, threadbound behaviour can be a bad idea. > For non blocking, async behaviour for example. There are relatively few > worker threads available and in many cases its unreasonable to tie up a > thread for a single subject for the life of a request. One thread may handle > many different users more or less simultaneously (waiting for callbacks > etc), so trying to manage where to bind & rebind threadlocals gets messy. > > the way I am using Shiro atm in a standalone app(havent updated yet), is > from an initial MethodInterceptor, I build a Subject from a given > sessionID,then I use the > subject.execute(new Callable() { > public Object call() throws Exception { > try { > return invocation.proceed(); > ... > > I use this just because it nicely decouples the interceptor from the rest of > my code and my app feels like a plain old webapp at this point, > I also happen to want a new thread at this point so its convenient. > > but in the invoked procedure I grab the subject and hand it around no longer > using the threadlocal reference. > eventually the callables' returned future is invoked and we're done. > > cheers. > > > > Les Hazlewood wrote: >> >> Hi Al (and any other standalone application users), >> >> This is somewhat of a long email, but your answers will give us >> direction how to present a solution for all Shiro users writing >> standalone applications - please read and reply if you can! >> >> Yes, we made some changes yesterday with how subject binding occurs >> after creation. The fix you used probably works for your environment >> (and might be totally fine in your case), but we can't say it is valid >> in all cases, which is why the behavior was changed. >> >> The issue here is that automatically binding to a ThreadLocal is maybe >> not the best approach for all environments. In a web app, this makes >> sense because there is framework code that will bind and unbind to the >> thread before and after request processing, respectively. We can >> always guarantee that the thread will be cleaned up after it is done >> executing or even when it throws an exception - so when that thread is >> used to process a different request, we can be sure it isn't >> 'polluted' with the Subject from a previous request. >> >> It is hard to make that guarantee for a standalone application. I >> mean, sure, we could bind the subject to the thread like you did to >> resolve your issue, but is it ok to keep that subject associated with >> that thread forever? If not, when should it be cleaned? It's >> impossible for us to answer that question for custom applications. >> >> For example, if we did the thread binding, and someone was writing a >> custom server and wanted to use Shiro to secure their server, then we >> certainly shouldn't bind to the thread automatically - the server >> should have some mechanism that performs the binding/unbinding for >> every request (RMI, REST, etc) that it receives (probably identical to >> our web approach). >> >> So, my question to you is - do you have any ideas of a good way this >> would work? How do you manage threads in your application? After you >> call subject.login, are any other threads that would need access to >> the subject? >> >> Your answers (or those from anyone else!) would greatly help us >> support standalone applications in a much cleaner manner. Please let >> us know! >> >> Thanks for any feedback, >> >> Les >> >> On Fri, Feb 19, 2010 at 7:42 AM, aloleary <[email protected]> wrote: >>> >>> I seem to be able to remedy with the following on startup: >>> >>> ThreadContext.bind(currentUser); >>> >>> but again wondering if this is something that recently changed or if it >>> points to some bad config on my side >>> >>> thanks >>> -- >>> View this message in context: >>> http://n2.nabble.com/SecurityUtils-getSubject-issue-tp4597560p4597613.html >>> Sent from the Shiro User mailing list archive at Nabble.com. >>> >> >
