That should would work too :)
On Thu, Jan 28, 2010 at 7:49 PM, Jason Eacott <[email protected]> wrote: > why not just mark the thread as daemon and fix it that way? > > Les Hazlewood wrote: >> >> Hi Phillipe, >> >> Ideally this should shut down without any problems. When Shiro >> discovers that you need Sessions, it automatically kicks off a thread >> to perform session validation at a regular interval to prevent >> orphaned sessions from eating up memory. >> >> So yes, the LifecycleUtils.destroy method will definitely work and is >> a good solution, but I think a more elegant solution might be to apply >> a Runtime hook to shut down the thread automatically. Could you >> please open a Jira issue for this? >> >> Thanks, >> >> Les >> >> On Wed, Jan 27, 2010 at 9:56 PM, Philippe Laflamme <[email protected]> >> wrote: >>> >>> Hi all, I'm using Shiro for a command line application. I'm instantiating >>> the SecurityManager exactly how it is specified on the wiki: >>> >>> Factory factory = new IniSecurityManagerFactory("classpath:shiro.ini"); >>> SecurityManager securityManager = factory.getInstance(); >>> SecurityUtils.setSecurityManager(securityManager); >>> >>> After authenticating a user, a new thread is spawned. Seems to be related >>> to >>> the default session management code. The problem I have is that this >>> thread >>> is never stopped, and so my command line never exists. I've found that >>> the >>> solution is to invoke destroy on the SecurityManager instance. Since the >>> method isn't part of the SecurityManager hierarchy, I've delegated the >>> call >>> to the LifecycleUtils class: >>> >>> LifecycleUtils.destroy(SecurityUtils.getSecurityManager()); >>> >>> This works fine, but I'm wondering if this is the suggested/correct >>> pattern. >>> It wasn't obvious, I had to inspect Shiro code. What's the recommended >>> approach? Thanks, Philippe >>> ________________________________ >>> View this message in context: Shutting down Shiro >>> Sent from the Shiro User mailing list archive at Nabble.com. >>> >> >
