Re: [equinox-dev] framework shutdown and bundle listeners

[Benjamin Reed <breed@xxxxxxxxxxxxxxx>]

I think that what you need can be accomplished using Start Levels. If the
core Eclipse bundles are start level 1 and the plugins are start level 2,
then when shutdown happens, you all plugins will be stopped before the core
Eclipse bundles are stopped.

ben

Rafael Chaves wrote:

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

Thanks,

Rafael

Peter Kriens <Peter.Kriens@xxxxxxxx> 11/08/2003 09:39 AM Please respond to pkriens

To:        Rafael Chaves/Ottawa/IBM@IBMCA         cc:                 Subject:        Re[4]: [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 ... :-)

Kind regards,

    Peter Kriens

RC> If there is an application whose main bundle is stopped, I believe it may
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 for a
RC> central service going away, and then react properly. But what if the
RC> regular application bundles don't know even how to shut down if the
RC> central bundle is not available? Stopping them from the central bundle's
RC> activator stop method seems to prevent regular bundles to remain active
RC> after the central bundle is stopped.

RC> The idea of distinguishing between a normal stop and a shutdown is to
RC> prevent the central bundle of trying to stop all dependant bundles when
RC> they have already been stopped (we know that because they have a higher
RC> start level). I know that to stop a stopped bundle is a no-op, but it must
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 make
RC> sense at all...

RC> Rafael





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>         cc:
RC>         Subject:        Re[2]: [equinox-dev] framework shutdown and bundle
RC> listeners


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 not
RC> make a distinction because we could not see how it could differ from
RC> the bundle's perspective.

RC> Kind regards,

RC>      Peter Kriens

RC>> Yes, Peter, it helps. So since the transition to STOPPING is not
RC> reflected
RC>> in events (there is no such event type), the way to check if the
RC> framework
RC>> is being shut down during a call to a bundle's activator stop method
RC> is to
RC>> check if the system bundle's state is STOPPING. That is enough for me.

RC>> Rafael





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> bundle
RC>> listeners


RC>> Synchronous bundle listeners are notified synchronous so they will
RC>> receive the events of all the bundles that are stopped before they are
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 delivered
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. events
RC>> when
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, these
RC>>> actions occur:

RC>>> "1. The system bundle enters the STOPPING state.

RC>>> 2. All ACTIVE bundles are suspended as described in the Bundle.stop
RC>>> method (...).

RC>>> 3. Event handling is disabled."

RC>>> Will synchronous BundleListeners be notified during step 2 (before
RC> the

RC>>> framework is shut down)? Can I assume that asynchronous bundle
RC>> listeners
RC>>> will never have a chance to be notified because of step 3?

RC>>> Thanks for any comments,

RC>>> Rafael






--
Peter Kriens                              Mob. +46705950899