Indeed, you could encounter a thread safety issue. The tidbit that you see (which, to be clear, is only intended for non-webapp use) is meant to be called at application startup time. So, call ``SecurityUtils.setSecurityManager`` only once in your application, in your main thread, prior to starting any other threads. After that you should not change it.
On Wed, Mar 5, 2014 at 5:14 AM, Romain Gilles <[email protected]>wrote: > Hi all, > First of all thank you for this framework! > I'm looking for a way to use the Shiro Guice integration. I'm looking to > the documentation and I see this: > > class MyShiroModule extends ShiroModule > > > then: > > Injector injector = Guice.createInjector(new MyShiroModule()); > SecurityManager securityManager = > injector.getInstance(SecurityManager.class); > SecurityUtils.setSecurityManager(securityManager); > > When I look at the > > SecurityUtils.setSecurityManager(securityManager); > > It look like this: > ... > private static SecurityManager securityManager; > ... > public static void setSecurityManager(SecurityManager securityManager) > { > SecurityUtils.securityManager = securityManager; > } > > Could we have a thread-safety issue here? > The SecurityManager attribute is not protected by volatile or lock. > > If I look at the different implementation I don' t see final usage and > volatile. > > How can I configure MyShiroModule to be sure that I will not encounter > multi-threading issue? > > Thanks, > > Romain. > > > > >
