[equinox-dev] Equinox tagged for next Helios M3 build.
One more fix for Equinox. The map file has been updated for the following Bug changes: + Bug 291396. [p2] Commit the extension bundle and the mili feature (REOPENED) The following projects have changed: org.eclipse.equinox.servletbridge Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] Equinox tagged for next Helios M3 build
The map file has been updated for the following Bug changes: + Bug 292935. [ds] need to add a p2.inf to set the equinox.use.ds property (FIXED) The following projects have changed: org.eclipse.equinox.ds Tom ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
[equinox-dev] DS and bundle stop/start
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@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
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 hargr...@us.ibm.com office: +1 386 848 1781 mobile: +1 386 848 3788 From: John Arthorne john_artho...@ca.ibm.com To: equinox-dev@eclipse.org Date: 2009/10/26 14:32 Subject: [equinox-dev] DS and bundle stop/start Sent by: equinox-dev-boun...@eclipse.org 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@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
