Fixed in the trunk, but there's no test for it. Les, you might want to look over it. It's not technically difficult to write a test for it but I didn't want to write it as part of this core module since it would require changing the unit test execution model to spawn a new process for each test. Added a TODO instead to implement the test as part of the standalone sample.
Kalle On Fri, Jan 29, 2010 at 6:21 AM, Les Hazlewood <[email protected]> wrote: > 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. >>>> >>> >> >
