On 14/05/13 16:46, Dan Gravell 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.
My fork doesn't do that and has proper activators and deactivators. You might be interested in it and add Mac and Windblows support??? > > 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] >> >> > -- Ferry Huberts --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
