Hi jrox,
Your issue is really similar to FileCleanerTracking issue from Apache
Commons-io.
If you are interested, see how them propose to solve the issue:
http://commons.apache.org/fileupload/apidocs/org/apache/commons/fileupload/servlet/FileCleanerCleanup.html
---------------------------------------------------------------------------------------------------------------------
Gustavo Henrique Orair
Mestre em Ciência da Computação - MSc in Computer Science
Universidade Federal de Minas Gerais
Celular/Cell phone: 55-31-85157887
------------------------------------------------------------------------------------------------------------------
2011/12/3 Andreas Loew <Andreas.Loew_at_oracle.com>:
> Hi jrox,
>
> Am 03.12.2011 20:38, schrieb forums_at_java.net:
>
> I have an MBean which is part of a war file. The application in that war
> file creates threads at startup. I now want to make sure that all threads
> get
> closed again when the application gets stopped/undeployed/redeployed. I am
> looking for the best way to do this and I found a few ideas but I am not
> sure
> if they work and which one would be best practice.
>
> 1. The MBean could be registered as a listener to JMX notifications, which
> can easily be done with Spring. But does the glassfish container send out
> notifications when undeploying an application (e.g. does glassfish
> unregister
> mbeans and therefore send out an MBeanServerNotification?). Who sends out
> that message, it it my own mbean? Can my mbean listen to an unregistering
> event of itself? .... lots of questions maybe someone can help me out here.
>
> 2. LifeCycle Module: can my LifeCycle module be in the same application war
> to which I want to listen to and intercept the undeployment command? How
> would I do that?
>
> 3. Any other easy options?
>
> as you are saying that you are using a WAR file, you have a much easier
> option than a LifeCycle module (which would be recommended the way to go in
> case of an EAR).
>
> You can define a startup servlet (via load-on-startup in web.xml) and use
> its methods init() to register and destroy() to deregister your
> application-related MBeans.
>
> Also, the important advantage here is that the current Thread context
> classloader in already is your WAR's web app classloader, which makes things
> much easier as you don't need to fiddle with switching the classloader back
> and forth to the appropriate classloader (as you would have to if you were
> to do the same from a Lifecycle module)...
>
> HTH & best regards,
>
> Andreas
>
> --
> Andreas Loew | Senior Java Architect
> Oracle Advanced Customer Services
> ORACLE Deutschland B.V. & Co. KG