Seems to me it should be enabled by default. Correct me if I'm wrong but wouldn't this only conflict between webapps if shiro was loaded from a shared classloader such as can occur with ear deployments (or if shiro is put in the server classpath)? And since I see the scenario mentioned previously as a rare case, this should seldom cause a problem. Another option for the multiple webapp case is to store it as an application-level attribute.
-Jared Les Hazlewood <[email protected]> wrote: Hi Jared, It wil definitely be configurable, but typically because there might be more than one Shiro-enabled web app in a single JVM (it'd be odd for a single app to have more than one Shiro SecurityManager). Right now in my local dev environment, it is disabled by default. But what is the 80/20 rule here? Should it be enabled by default, with the option to turn it off? Or keep it disabled by default (as it is now), and expect people to manually turn it on? Shiro's general premise is to make things as easy as possible. Will more people expect it to 'just work' without having to specify this extra config option? Or will more people be running more than one Shiro-enabled web app in the same JVM? Thoughts? HTH, Les On Wed, Apr 20, 2011 at 7:24 PM, Jared Bunting <[email protected]> wrote: > Les, > > Will this be disableable via an option on the filter? I can see where a > webapp with more than one shiro filter / security manager would cause a > problem with this. > > -Jared > > "Les Hazlewood (JIRA)" <[email protected]> wrote: > > Enable web-configured SecurityManager to be statically accessible for > non-request threads > ------------------------------------------------------------------------ -- > --------------- > > Key: SHIRO-287 > URL: https://issues.apache.org/jira/browse/SHIRO-287 > Project: Shiro > Issue Type: New Feature > Reporter: Les Hazlewood > Assignee: Les Hazlewood > Fix For: 1.2.0 > > > For any work done on threads that are not triggered by a request thread, > the SecurityManager should be accessible to these threads so the > Subject.Builder can be used properly. > > This can be accomplished by setting the configured SecurityManager as a > static member variable in SecurityUtils (via > SecurityUtils.setSubjectManager). While static memory is not ideal, it is > probably good enough for 90% of web applications, and can be a viable > solution. > > -- > This message is automatically generated by JIRA. > For more information on JIRA, see: http://www.atlassian.com/software/jira
