Static Singleton SecurityManager

[Les Hazlewood <lh...@apache.org>]

I was thinking this morning about configuring a JSecurity environment that
is not a webapp and does not use a microcontainer.

Typically I configure JSecurity in this situation with Spring, as that is my
container of choice.  However, if an end user does not want to use Spring or
Guice or any other MC, or they have a relatively simple application, such as
use in an Applet or even a standalone desktop environment, they have one of
two choices:

1)  Manually manage where the SecurityManager runtime instance is stored and
accessed or
2)  call SecurityUtils.setSecurityManager(SecurityManager sm), which stores
the securityManager instance as a static class attribute.  Then any time the
application calls SecurityUtils.getSubject() or
SecurityUtils.getSecurityManager(), the statically stored SecurityManager is
used.

#2 is not preferential since non-static singletons are easier to manage, but
it exists to support environments that don't maintain their own
microcontainer or #1.  So, to that end, I was thinking the following would
be convenient:

DefaultSecurityManager.setStaticSingleton(true/false);

This would delegate to SecurityUtils.setSecurityManager(this) to enable
static access.  The impetus for this is for 'proper' configuration in a
non-web environment.  While configuring other attributes in the .ini file, I
could also do:

securityManager.staticSingleton = true

and the securityManager would be accessible application-wide with no further
configuration.  The ideal scenario is that they don't have to (in Java code)
interact with the SecurityManager any further.

It is already JavaDoc'd quite clearly that the preferred approach is an
application (non static) singleton, but this fallback approach is very
useful in non-webapps.

Any objections to me adding this passthrough property?

Thanks,

Les