Alin:
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.
You are making a good point here, except that I think that "stopping" is maybe not a good choice. Actually it's not recommendable to stop threads at all, it is a thread primitive that has been deprecated a while ago:
http://java.sun.com/j2se/1.3/docs/guide/misc/threadPrimitiveDeprecation.htmlHowever, it may make sense to handle this case, and maybe to join the start thread before proceeding with a stop.
As a side note, I always found it semantically strange to have "starting" and "stopping" as states (4.3.2 Bundle States), rather than "transitions".
Stopping:Knopflerfish seems to assume that when a bundle is stopped, the frameworkshould 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, ...
Good point, with the same exception as above (stopping threads may not be a good idea).
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.
I usually try to design the use of other services in a way that allows "come and go". i.e. using a mediated reference instead of obtaining one and holding it; and kind of doing request/response transactions.
However, I have come to the conclusion that if state needs to be maintained between calls to a service, then it is actually much more complex to handle (and design for) the "come and go" situation.
Regards, Dieter
smime.p7s
Description: S/MIME cryptographic signature
