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.
