On 14/05/13 16:35, Dan Gravell 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
Wow, another 'classic': think about starting up, but not about shutting down... That library might be more trouble than it's worth... grtz BTW. I just updated my JNotify fork to use a modern bndtools workspace > 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] >> >> > -- Ferry Huberts --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
