On Wed, Apr 20, 2011 at 6:07 PM, dan <[email protected]> wrote:
> Hi Les,
>
> Yes, in my first post I didn't want to overwhelm you with irrelevant details
> so it was a bit short... ;)
>
> Our app currently uses Shiro in the standard web servlet way, that is, I
> have IniShiroFilter in my web.xml file and all incoming http requests are
> intercepted by Shiro. In my shiro.ini, I don't specify a securityManager
> class, so it decides to instantiate a DefaultWebSecurityManager on its own,
> which is fine.
>
> For our deamon processes, we have a web filter and within its init() method,
> we instantiate some objects, including a singleton, initialize our scheduler
> and then process to kick off Java threads here and there. In my deamon
> task, when I call getSecurityManager(), it can't find any threadlocal
> information (which I expect). Then it tries the static secuirtyManager which
> also returns null so the exception is thrown.
Ah, I see now.
At the moment, it is expected that work on other threads is 'kicked
off' from a request-initiated thread. That is, during a web request,
when there is a Subject available, you can call subject.associateWith*
and take the resulting object and toss it off to an ExecutorService
(or better yet, use Shiro's SubjectAwareExecutorService
implementations so you don't have to use the subject directly).
But, assuming you don't want to do this (or can't do this), there is
an easy, albeit not ideal, solution:
Subclass the IniShiroFilter and override the init() method:
public void init() {
super.init();
SecurityUtils.setSecurityManager(getSecurityManager());
}
and specify that class in web.xml
That will ensure that all uses of SecurityUtils.getSecurityManager()
will fall back to static memory if one is not available on the current
thread.
To solve this in a better way, I just created
https://issues.apache.org/jira/browse/SHIRO-287
It will be easy enough to implement this shortly such that it will be in 1.2.
HTH!
Les
