They are in “lazy” state after refresh. I assumed it’s the same as “starting” 
and naming difference is just console sugar. Is it actually?

My expectation here is that lazy activation (transition to “starting” state) 
happens after bundle.start() method is called.
As far as I know bundle state transition resolve -> active should happen only 
after explicit start call.  I still don’t see on which of the steps I’m 
performing  this explicit call could happen.
Or you mean that equinox refresh command does “start” under the hood? Is there 
more information on equinox compatibility option you mentioned (source pointers 
would do as well)?

I checked the bug you pointed to – just to be clear-  my test playground 
contains only equinox and the attached bundles so I think that simple 
configurator and p2 shouldn’t be a concern (this time ☺) and it’s more pure 
framework question.
(I’m not sure I’m able to get the context just by reading the bug comments but 
it seems it describes a weak point in sc, so I’ll ask the p2 guys for more 
information)

Why this seems a problem from my point of view: first load of a class should 
not start a bundle – otherwise one may not be able to use a bundle as a library 
just for class loading but would be forced to pay the activation price.

To be sure I understand correctly – you say that implicit bundle activation 
after installation is equinox feature and it’s enabled by setting 
bundle-activationPolicy to lazy?

Thanks for the help,
Katya



From: [email protected] [mailto:[email protected]] 
On Behalf Of Thomas Watson
Sent: mercredi 28 septembre 2011 15:14
To: Equinox development mailing list
Subject: Re: [equinox-dev] Bundle lazy activation


From the console, what state are the bundles in after calling refresh? I 
suspect they are in the STARTING (actually lazy starting) state. This means 
they are waiting for the first class load and then will be acivated. In equinox 
we have had lazy activation since day one, before it was in the OSGi 
specification. As such we do have a compatibility option which is enabled by 
default that marks any lazy activate for start once it is installed. Also see 
p2 bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=177641.

I suspect you are seeing a case where the two lazy activation bundles you 
installed being marked for using the lazy start policy upon installation which 
makes them ready to start as soon as they get their first class load.

Tom



[cid:[email protected]]"Todorova, Katya" ---09/28/2011 06:08:36 
AM---Hi guys,

From:


"Todorova, Katya" <[email protected]>


To:


Equinox development mailing list <[email protected]>,


Date:


09/28/2011 06:08 AM


Subject:


[equinox-dev] Bundle lazy activation

________________________________



Hi guys,

I’m experiencing a strange bundle “auto start” behavior – let’s have two 
bundles which are declared to be lazy activated, first providing a class 
referenced by the second one.
After installing them and calling refresh, I start the “consumer” (via console 
command) which in turn activates the other one. I checked the spec and it says:
“A lazy activation policy indicates that the bundle, once started, must not be 
activated until it receives the first request to load a class”

I’m confused because I haven’t started the provider explicitly and I expected 
it to be in resolved state and not to be activated at all. Do I miss something?
Test bundles attached.

Thank you,
Katya
[attachment "TestLazy_1.0.0.201109281137.jar" deleted by Thomas 
Watson/Austin/IBM] [attachment "TestLazyConsumer_1.0.0.201109281137.jar" 
deleted by Thomas Watson/Austin/IBM] 
_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev

<<inline: image001.gif>>

<<inline: image003.png>>

<<inline: image004.png>>

_______________________________________________
equinox-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/equinox-dev

Reply via email to