Re: [equinox-dev] DS and bundle stop/start

[John Arthorne <John_Arthorne@xxxxxxxxxx>]

Yes, in an ideal world everyone would
handle all services completely dynamically. In reality this adds a lot
of complexity to application code, so people make simplying assumptions
that services provided by bundles they require are already available (since
referencing the service interface would cause that bundle to be activated
and the service made available). In my particular case the bundle was assuming
that a service provided by *itself* was already registered if the bundle
was activated. This was true when the bundle was registering that service
in its activator, but when that registration was moved to DS it opened
a new window in which the bundle is activated but the service is not registered
- only in the case where the bundle has been started explicitly via Bundle.start().
This is a subtle difference that is likely to bite people as they switch
to DS.

John

BJ Hargrave <hargrave@xxxxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

10/27/2009 10:41 AM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc
Subject	Re: [equinox-dev] DS and bundle stop/start

Yes. No bundle should expect another
bundle to register some service during it activation. A bundle should depend
upon services using DS or ServiceTracker (or even ServiceListener).
--

BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance hargrave@xxxxxxxxxx

office: +1 386 848 1781 mobile: +1 386 848 3788

From:	Thomas Watson/Austin/IBM@IBMUS
To:	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:	2009/10/27 09:54
Subject:	Re: [equinox-dev] DS and bundle stop/start
Sent by:	equinox-dev-bounces@xxxxxxxxxxx

---

Hmmm, I thought the original design of lazy activation and DS components
was to synchronously make service components available in the service registry
as long as they are immediately resolvable. The reason for this was to
ensure these services were synchronously available before we entered the
Eclipse application entry point.

This points out a deficiency in the way most of Eclipse handles dynamic
registration of services. If every eclipse bundle was written from day
one to handle dynamic registration and unregistration of services then
it would not matter that the service registration happened asynchronously.

Tom

BJ
Hargrave---10/26/2009 03:27:34 PM---Why doesn't DS just asynchronously
process bundles which are lazy activated (not lazy started which is an
incorrect term)? Then

From:	BJ Hargrave/Austin/IBM@IBMUS
To:	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:	10/26/2009 03:27 PM
Subject:	Re: [equinox-dev] DS and bundle stop/start

---

Why doesn't DS just asynchronously process bundles which are lazy activated
(not lazy started which is an incorrect term)? Then you have the same behavior
(async processing) regardless of whether the bundle is lazily or eagerly
activated. 
--

BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance 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

_______________________________________________
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