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

["Rafael Chaves" <Rafael_Chaves@xxxxxxxxxx>]

(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