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 J) 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: equinox-dev-bounces@xxxxxxxxxxx [mailto:equinox-dev-bounces@xxxxxxxxxxx] 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
"Todorova, Katya" ---09/28/2011 06:08:36 AM---Hi guys,
From:
| "Todorova, Katya" <katya.todorova@xxxxxxx>
|
To:
| Equinox development mailing list <equinox-dev@xxxxxxxxxxx>,
|
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
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev