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

[BJ Hargrave <hargrave@xxxxxxxxxx>]

Why not have DS hand off processing of
the components to another thread when the LAZY_ACTIVATION event is received?
This will allow the bundle start to complete while the DS processing occurs
async.

I don't think we should change to process
on STARTING.

This whole discussion seems to point
out that we are, perhaps unwisely, blending using DS and BundleActivator
where the activators have a dependency on DS having alread processed the
bundle. Perhaps what is needed is a form of immediate component that is
not activated when DS processed the bundle but is activated when the bundle's
STARTED event is fired. This would delay creation of the immediate component
until the bundle activation was lazily triggered and allow the immediate
component to be injected with any other services of the bundle.

This design change seems a much better
idea that combining BundleActivators and DS with specific ordering.
--

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:	Stoyan Boshev <s.boshev@xxxxxxxxxxx>
To:	Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
Date:	2009/10/27 11:24
Subject:	Re: [equinox-dev] DS and bundle stop/start
Sent by:	equinox-dev-bounces@xxxxxxxxxxx

---

BJ Hargrave wrote:
> 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.

The DS components of activated bundles are processed by DS when it 
receives BundleEvent.STARTED (for normal activated bundles) or 
BundleEvent.LAZY_ACTIVATION (for lazy activated bundles). These events
are processed in DS by a SynchronousBundleListener.
Actually DS processes synchronously the components in both cases. The 
difference comes with the fact that BundleEvent.STARTED is sent by the
framework after the bundle's activator is started.
We cannot modify DS to process only BundleEvent.STARTED because in this
case lazy activated bundles will not be processed at all.

What we can do in DS is to process the DS components of a bundle when DS
receives BundleEvent.STARTING event instead of BundleEvent.STARTED. This
way DS will process the components before the framework calls the bundle
activator's start method and the behavior would be similar to the one 
when processing lazy activated bundles. However, the DS specification 
always speaks of DS processing started bundles. So, I am not sure 
whether it is appropriate to process the DS components of a bundle 
before it is fully started.

Stoyan


> -- 
> 
> *BJ Hargrave*
> Senior Technical Staff Member, IBM
> OSGi Fellow and CTO of the _OSGi Alliance_ <http://www.osgi.org/>_
> __hargrave@xxxxxx.com_ <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

-- 
---------------------------------------------------------
dipl. eng. Stoyan Boshev . Department manager
ProSyst Labs EOOD
1606 Sofia, Bulgaria . 48 Vladajska Str.
Tel. +359 2 953 05 88; Fax +359 2 953 26 17
Mobile: +359 88 898 29 17
http://www.prosyst.com
. s.boshev@xxxxxxxxxxx
---------------------------------------------------------
stay in touch with your product
---------------------------------------------------------
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev