I'd remove JNotify and replace it with the new filesystem classes in J2SE 7. That way you'll be able to sort out the thread management yourself.
On 14 May 2013, at 15:46, Dan Gravell <[email protected]> wrote: > Hmmmm, sorry, don't want to misrepresent things... In neither case do you > *explicitly* start threads. > > JNotify's threads are started by the class initialisers... so load the > class (as you do when you add a 'watch' via a static method for a > directory) and the thread starts. > > Lift's are started as part of its HTTP request handling. I managed to patch > it to stop all the threads upon shutdown of its surrounding servlet > container (I use Jetty) but this is just code I will have to maintain going > forward with new releases. > > Neither behaviour is particularly desirable but JNotify's age and lack of > committers and Lift's usage scenarios are probably good reasons why the > respective projects' resources are not spent on fixing this. > > Dan > > > On Tue, May 14, 2013 at 3:41 PM, Neil Bartlett <[email protected]> wrote: > >> So, they give you API to start a bunch of threads, but not stop them? >> Awesome... >> >> On Tue, May 14, 2013 at 3:35 PM, Dan Gravell <[email protected]> >> wrote: >>> In one case (JNotify) I create straight wrappers so the JARs are >>> 'OSGi-ified', in another case I have the JARs embedded in the bundle that >>> uses them (Lift). >>> >>> Adding the bundle activator might work if the support to shutdown the >>> threads is in the API for the code I am using. However, it isn't, and as >>> you know Java threads are co-operative so I can't simply stop them. >>> >>> Dan >>> >>> >>> On Tue, May 14, 2013 at 2:57 PM, Felix Meschberger <[email protected] >>> wrote: >>> >>>> Hi Dan, >>>> >>>> Am 14.05.2013 um 07:16 schrieb Dan Gravell: >>>> >>>>>> With respect to when the thread has to stop, think about it the other >>>>>> way around... what if you never stop any threads? This would mean >> that >>>>>> objects allocated by the thread do not become candidates for garbage >>>>>> collection; therefore neither do the classes that define those >>>>>> objects; therefore, neither do the classloaders that loaded those >>>>>> classes. So you're going to create a lot of garbage on the heap, >>>>>> eventually resulting in OOME. Also, if a bundle's thread continues >>>>>> running after the bundle has been stopped/updated then you could get >>>>>> unexpected exceptions occurring in that thread; e.g. the bundle >>>>>> classloader might not allow any new classes to be loaded, and calls >>>>>> into OSGi using your BundleContext will probably throw >>>>>> IllegalStateException. Generally these exceptions are not harmful >>>>>> since you wanted the thread to die anyway, but they could cause >>>>>> confusion if written to a log. >>>>>> >>>>> >>>>> Just to be clear: you're preaching to the converted, I understand why >> the >>>>> threads should be stopped. The issue is that I am re-using other >> projects >>>>> that don't conform to these rules.... projects that were never >> written as >>>>> OSGi bundles. It's a bit like the class loading assumptions you see in >>>>> other projects... except arguably more subtle. >>>> >>>> So you are using libraries which are not built with OSGi in mind. Still >>>> you need OSGi manifests for the libraries to become bundles. So you at >>>> least wrap the libraries somehow to generate the manifest. >>>> >>>> How about adding a BundleActivator as part of this manifest generation ? >>>> That BundleActivator could in the stop method stop any running threads. >> The >>>> BundleActivator is part of the bundle so it may be aware of the library >>>> internals and be able to stop any running threads. >>>> >>>> Regards >>>> Felix >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> This e-mail is only intended for the person(s) to whom it is addressed and may contain CONFIDENTIAL information. Any opinions or views are personal to the writer and do not represent those of INQ Mobile Limited, Hutchison Whampoa Limited or its group companies. If you are not the intended recipient, you are hereby notified that any use, retention, disclosure, copying, printing, forwarding or dissemination of this communication is strictly prohibited. If you have received this communication in error, please erase all copies of the message and its attachments and notify the sender immediately. INQ Mobile Limited is a company registered in the British Virgin Islands. www.inqmobile.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
