I missed this question down in my inbox,
sorry for the late response.
What did you have in mind for update.configurator
and application shutdown? Currently update.configurator has no notion
of an application. It just follows some policy to install a set of
bundles. In 3.3 M5 there are two ways an eclipse application can
1) It chooses to exit. In the
case of the SDK workbench this is user driven (i.e. the user decides to
2) The ApplicationHandle.destroy() method
is called, this eventually causes the application's implementation of IApplication.stop()
to be called which should force the application to exit.
In both cases this causes the Framework
to proceed with shutdown and exit, update.configurator does not have to
do anything. This is the default behavior for the eclipse application
container. There are additional configurations available to allow
multiple eclipse applications to be launched and shutdown without causing
the framework to shutdown. Even in this case I do not see how update.configurator
would get involved unless you want update.configurator to be the one to
decide what applications to run and to make the decision of when to exit
the framework. Currently we do not have such a bundle making these
types of decisions. We only have the notion of a default application
that is run on startup.
Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx> Sent by: equinox-dev-bounces@xxxxxxxxxxx
02/05/2007 09:25 PM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
[equinox-dev] OSGi new startup policies
Even though the changes coming down from OSGi around bundle activation
should be backward compatible, I wonder if there is anything that should
be done in update.configurator and the way we shutdown the application?
equinox-dev mailing list