(the following thread went private accidentaly.
But since it is of general interest, I am fixing my mistake...)
Peter, I should have made it clear sooner,
but the main bundle I am talking about is the Eclipse runtime, and regular
bundles would be Eclipse bundles (the ones with extensions/extension points).
So, despite my sincere admiration of
OSGi's decoupled nature, it is still unclear (at least for me) whether
Eclipse bundles should be able to exist in the absence of the Eclipse runtime.
If they should not, we need to enforce that all Eclipse bundles are stopped
before the Eclipse runtimeis closed for business. A service event notification
is simply too late.
About bundle hierarchies being bad,
in general, I agree, but I believe that Eclipse on top of OSGi still provides
a platform for its bundles, and it makes sense to me that Eclipse bundles
require this platform to run, and conversely that the platform knows about
the "managed" bundles (right now, the extensions registry is
where this knowledge is kept).
Again, sorry for not making explicit
which bundles I was talking about since the beginning.
Peter Kriens <Peter.Kriens@xxxxxxxx>
11/08/2003 09:39 AM
Please respond to pkriens
Re: [equinox-dev] framework shutdown
and bundle listeners
I guess this should be one of the issues we should
discuss in the
scope concept. It does not seem like a good idea that the "main"
bundle knows about its children, and it is also not attractive that
the children have to watch the "main" bundle.
In OSGi, so far, we like to express the dependencies via services.
That is much more decoupled and gives more freedom later. Creating
bundle hierarchies sounds a bit scary to me ... :-)
RC> If there is an application whose main bundle is stopped, I believe
RC> make sense to stop all other application bundles from the main bundle's
RC> activator stop method. Of course, the other bundles could watch
RC> central service going away, and then react properly. But what if
RC> regular application bundles don't know even how to shut down if
RC> central bundle is not available? Stopping them from the central
RC> activator stop method seems to prevent regular bundles to remain
RC> after the central bundle is stopped.
RC> The idea of distinguishing between a normal stop and a shutdown
RC> prevent the central bundle of trying to stop all dependant bundles
RC> they have already been stopped (we know that because they have a
RC> start level). I know that to stop a stopped bundle is a no-op, but
RC> have some cost, which multiplied by 5000 may not be that irrelevant.
RC> I am pretty new to all this, so I won't be surprised this does not
RC> sense at all...
RC> Peter Kriens <Peter.Kriens@xxxxxxxx>
RC> 11/08/2003 12:52 AM
RC> Please respond to pkriens
RC> To: Rafael Chaves/Ottawa/IBM@IBMCA
RC> Subject: Re:
[equinox-dev] framework shutdown and bundle
RC> What is the use case to differ between a normal stop and a shutdown
RC> stop? We had lots of discussion around this subject and decided
RC> make a distinction because we could not see how it could differ
RC> the bundle's perspective.
RC> Kind regards,
RC> Peter Kriens
RC>> Yes, Peter, it helps. So since the transition to STOPPING is
RC>> in events (there is no such event type), the way to check if
RC>> is being shut down during a call to a bundle's activator stop
RC> is to
RC>> check if the system bundle's state is STOPPING. That is enough
RC>> Peter Kriens <Peter.Kriens@xxxxxxxx>
RC>> 08/08/2003 12:46 PM
RC>> Please respond to pkriens
RC>> To: Rafael Chaves/Ottawa/IBM@IBMCA
RC>> cc: equinox-dev@xxxxxxxxxxx
RC>> Subject: Re:
[equinox-dev] framework shutdown and
RC>> Synchronous bundle listeners are notified synchronous so they
RC>> receive the events of all the bundles that are stopped before
RC>> stopped and their own.
RC>> With async bundle listeners it is not defined because the event
RC>> delivery is async from the actual event. Events must not be
RC>> to bundles that are stopped.
RC>> Does this help?
RC>> Kind regards,
RC>> Peter Kriens
RC>>> Reading the OSGi spec, the semantics of what happens w.r.t.
RC>>> shutting down the framework (e.g. with "stop 0")
are not clear:
RC>>> According to section 4.19.2, when shutting down the framework,
RC>>> actions occur:
RC>>> "1. The system bundle enters the STOPPING state.
RC>>> 2. All ACTIVE bundles are suspended as described in the
RC>>> method (...).
RC>>> 3. Event handling is disabled."
RC>>> Will synchronous BundleListeners be notified during step
RC>>> framework is shut down)? Can I assume that asynchronous
RC>>> will never have a chance to be notified because of step