I know this is a little late, but it looks good to me! Cheers,
Les On Fri, Jan 29, 2010 at 4:54 PM, Kalle Korhonen <[email protected]> wrote: > 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. >>>>> >>>> >>> >> >
