felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: General questions about starting and stopping bundles
Date Tue, 01 Jul 2008 21:19:44 GMT
Dieter Wimberger wrote:
> 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.html 
> However, 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".

Well, I think the suggestion was intended to say, "make sure the threads 
exit properly"...since this is all in one bundle, I assume that you 
would be able to set some flag on the thread to make it stop...

-> richard

>>> 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, ...
> 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

View raw message