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]
