--
*BJ Hargrave*
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the _OSGi Alliance_ <http://www.osgi.org/>_
__hargrave@xxxxxxxxxxx <mailto:hargrave@xxxxxxxxxx>
office: +1 386 848 1781
mobile: +1 386 848 3788
From: John Arthorne <John_Arthorne@xxxxxxxxxx>
To: equinox-dev@xxxxxxxxxxx
Date: 2009/10/26 14:32
Subject: [equinox-dev] DS and bundle stop/start
Sent by: equinox-dev-bounces@xxxxxxxxxxx
------------------------------------------------------------------------
I came across an interesting problem today involving DS and expicitly
starting/stopping bundles. After chatting with Tom he suggested I raise
it here for general awareness and to discuss whether the behaviour makes
sense.
In various places in p2 today we explicitly start bundles for various
reasons. We typically use Bundle.start(Bundle.START_TRANSIENT) for this
purpose. We are starting to use DS in p2 today, and we have a few places
where a bundle acquires a service that it registered via DS in its own
BundleActivator.start method. It turns out that DS only processes/starts
service components synchronously for bundles that are lazy started. If
you start a bundle explicitly the DS processing occurs asynchronously,
and as a result the services provided via DS are not available at the
time the bundle starts. The result is subtlely different bundle
behaviour (or outright failures), if a bundle is started explicitly via
Bundle#start versus implicitly via lazy activation:
1) Lazy start case:
a) bundle's service component is processed and services provided by the
component are registered by DS
b) bundle activator starts, and can use services registered in 1a)
2) Activation via Bundle.start(Bundle.START_TRANSIENT):
a) bundle's activator starts, and services are not yet available
b) bundle's service component is processed and services provided by the
component are registered by DS
It turns out there is a coding pattern that can be used to make the
explicit start case match the lazy start case:
*final* Bundle bundle = ...;//get some bundle
bundle.start(Bundle.START_ACTIVATION_POLICY);
bundle.start(Bundle.START_TRANSIENT);
The call to start(Bundle.START_ACTIVATION_POLICY) causes DS to process
the bundle and register its component services, but does not start the
bundle. The second call to start with Bundle.START_TRANSIENT actually
starts the bundle.
The moral of the story seems to be that we need to use this "double
start" coding pattern anywhere we are starting bundles, because those
bundles might be using DS and relying on the activation order. Or,
perhaps someone has a suggestion for changes that can be made to the
framework or DS so that these cases behave consistently...
John_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
------------------------------------------------------------------------
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev