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
