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
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|BJ Hargrave/Austin/i...@ibmus
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Equinox development mailing list <[email protected]>
|
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| 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 office: +1 386 848
Member, IBM 1781
OSGi Fellow and CTO of the mobile: +1 386 848
OSGi Alliance 3788
[email protected]
From: John Arthorne <[email protected]>
To: [email protected]
Date: 2009/10/26 14:32
Subject: [equinox-dev] DS and bundle stop/start
Sent by: [email protected]
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
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
