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] > >
