Returns the SecurityManager accessible to the calling code. <p/> This implementation favors acquiring a thread-bound {@code SecurityManager} if it can find one. If one is not available to the executing thread, it will attempt to use the static singleton if available (see the {@link #setSecurityManager setSecurityManager} method for more on the static singleton). <p/> If neither the thread-local or static singleton instances are available, this method {@code UnavailableSecurityManagerException} to indicate an error - a SecurityManager should always be accessible to calling code in an application. If it is not, it is likely due to a Shiro configuration problem.
Returns the currently accessible {@code Subject} available to the calling code depending on runtime environment. <p/> This method is provided as a way of obtaining a {@code Subject} without having to resort to implementation-specific methods. It also allows the Shiro team to change the underlying implementation of this method in the future depending on requirements/updates without affecting your code that uses it.
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>
Accesses the currently accessible {@code Subject} for the calling code depending on runtime environment.