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]
