On Sat, Jun 28, 2008 at 12:46 AM, Dieter Wimberger <[EMAIL PROTECTED]> wrote: > Hi all, > > I have got some general questions about starting and stopping bundles. > > Given that I made my first OSGi steps with Knopflerfish, I have usually been > following their general recommendations on bundle design: > http://www.knopflerfish.org/programming.html > > Starting: > Konpflerfish seems to suggest to spawn a thread if bundle activation is > supposed to take a while. > (See section "Spawning a startup thread"). > > This basically translates to the following construct: > > public void start(final BundleContext bundleContext) throws Exception { > c_BundleContext = bundleContext; > > Thread t = new Thread( > new Runnable() { > public void run() { > ///do start logic > }//run > }//Runnable > );//Thread > > t.setContextClassLoader(getClass().getClassLoader()); > t.start(); > }//start > > > Is this approach recommendable? Are there side-effects that could be > container dependent?
The specs does not mandate this but I see it as a best practice when the start method does not return in a "timely manner". Having this thread also means that you must take care to stop the thread during BundleActivator.stop as it can be that stop is called before your starting thread ends. > > Stopping: > Knopflerfish seems to assume that when a bundle is stopped, the framework > should be taking care about unregistering services. > (See "Automatic cleanup of services") > > Is this generally valid or container dependent? This is mandated by the core specs (section 4.3.6 on specs 4.0.1). > Also, does this also apply to Listener instances (like for example a > ServiceListener) and service references that are being used? > I.e. is there a need to call BundleContext.removeService/FrameworkListener() > or m_BundleContext.ungetService() for cleanup? In principle you should "undo" what you did during start, so release resources, stop started threads, ... There is no need to unregister services registered during startup or framework listeners because they will be cleaned up by the framework after the stop method returns. Also, any services used by the bundle being stopped will be released automatically by the framework. But recall that other bundles that still have references to your service will still be able to call your service so you may wanna play defense and handle this case even if I consider this a programming error from the point of view of the bundle that still uses the service even if the service has been unregistered. When I wanna do that I usually implement the service using a state service and by the moment the bundle is stopped or the service s unregistered I change the internal state of the service to stopped, state where I throw an meaningful exception. But is a lot of work in plus that does not bring real value to your service, it only helps the developer of the bundle that is still using the invalid service to think about the fact that he should not use anymore the service after it has been unregistered. > > Any comments and answers are appreciated. > > Regards, > Dieter > > > > -- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development. http://malaysia.jayway.net - New Energy for Projects - Great People working on Great Projects at Great Places
