Sets a VM (static) singleton SecurityManager, specifically for transparent use in the
{@link #getSubject() getSubject()} implementation.
<p/>
<b>This method call exists mainly for framework development support. Application developers should rarely,
if ever, need to call this method.</b>
<p/>
The Shiro development team prefers that SecurityManager instances are non-static application singletons
and <em>not</em> VM static singletons. Application singletons that do not use static memory require some sort
of application configuration framework to maintain the application-wide SecurityManager instance for you
(for example, Spring or EJB3 environments) such that the object reference does not need to be static.
<p/>
In these environments, Shiro acquires Subject data based on the currently executing Thread via its own
framework integration code, and this is the preferred way to use Shiro.
<p/>
However in some environments, such as a standalone desktop application or Applets that do not use Spring or
EJB or similar config frameworks, a VM-singleton might make more sense (although the former is still preferred).
In these environments, setting the SecurityManager via this method will automatically enable the
{@link #getSubject() getSubject()} call to function with little configuration.
<p/>
For example, in these environments, this will work:
<pre>
DefaultSecurityManager securityManager = new {@link hunt.shiro.mgt.DefaultSecurityManager DefaultSecurityManager}();
securityManager.setRealms( ... ); //one or more Realms
<b>SecurityUtils.setSecurityManager( securityManager );</b></pre>
<p/>
And then anywhere in the application code, the following call will return the application's Subject:
<pre>
Subject currentUser = SecurityUtils.getSubject();</pre>
@param securityManager the securityManager instance to set as a VM static singleton.
Sets a VM (static) singleton SecurityManager, specifically for transparent use in the {@link #getSubject() getSubject()} implementation. <p/> <b>This method call exists mainly for framework development support. Application developers should rarely, if ever, need to call this method.</b> <p/> The Shiro development team prefers that SecurityManager instances are non-static application singletons and <em>not</em> VM static singletons. Application singletons that do not use static memory require some sort of application configuration framework to maintain the application-wide SecurityManager instance for you (for example, Spring or EJB3 environments) such that the object reference does not need to be static. <p/> In these environments, Shiro acquires Subject data based on the currently executing Thread via its own framework integration code, and this is the preferred way to use Shiro. <p/> However in some environments, such as a standalone desktop application or Applets that do not use Spring or EJB or similar config frameworks, a VM-singleton might make more sense (although the former is still preferred). In these environments, setting the SecurityManager via this method will automatically enable the {@link #getSubject() getSubject()} call to function with little configuration. <p/> For example, in these environments, this will work: <pre> DefaultSecurityManager securityManager = new {@link hunt.shiro.mgt.DefaultSecurityManager DefaultSecurityManager}(); securityManager.setRealms( ... ); //one or more Realms <b>SecurityUtils.setSecurityManager( securityManager );</b></pre> <p/> And then anywhere in the application code, the following call will return the application's Subject: <pre> Subject currentUser = SecurityUtils.getSubject();</pre>
@param securityManager the securityManager instance to set as a VM static singleton.