Hi Konrad,
in my early days, I was under a similar impression and was wondering what the logic behind all this is. The first thing is: it is more of an eclipse then an OSGi thing.
Components:
Components by themself have no influence of on the starting behavior of the bundle it lives in. If a Bundle is Started (or even in state starting, not sure) DS will recognize it and handle its declared components. If a Component is a Service and has immediate=true, it will activate the service the moment all its references are satisfied. Components without a Service are immediate by default. Thus: DS will not start your Bundles.
Bundle-ActivationPolicy: lazy
After a Bundle is installed, the Framework tries to resolve it. So the Resolve states means, that all its Imports and Requirements are satisfied and it is exacted that all is classes can be properly loaded. At this point other bundles can load the Exported Classes from the Bundle. This does require a Bundle to be active. Active only means that a Bundle Activator (if present) was called and that Components, Configurations or what ever else lurks in the Bundle has started doing something.
If the Bundle-ActivationPolicy is not lazy, it will be started automatically after the resolve state. If I have read the code correctly, this is done by the launcher who sits outside and not really framework itself.
Equinox has a bit of a special handling. Its Launcher (called EclipseStarter) installs all configured Bundles and then tries to start them if they don't have the Lazy policy. It then goes through the Lazy List and tries to start them according to the configured start levels. (I hope I've gotten the order right here). So Lazy in the pure OSGi sense means, don't autostart as somebody will do it manually at some point.
So, when you want your Bundle to be started and your Components to be available don't set it to lazy (or in case of Eclipse and RCP you can also set a startlevel for it).
Hope this helps,
Jürgen.
Am 29/09/2022 um 17:56 schrieb Konrad Windszus:
Hi,
I observed an issue in Equinox with Bundles not being automatically started although they do have DS components with an immediate flag in it.
From https://docs.osgi.org/specification/osgi.core/8.0.0/framework.lifecycle.html#i3270328 it is not quite clear to me under which circumstances the framework can decide to leave a bundle in RESOLVED state.
It seems to depend on its internal autostart setting, which according to chapter 4.4.5 of OSGi Core can have one of three values:
• Stopped - The bundle should not be started.
• Started with eager activation - The bundle must be started once it is ready and it must then be eagerly activated.
• Started with declared activation
Under which particular circumstances is a Framework supposed to start a bundle automatically (given its autostart setting is not set to Stopped)
1. Once a class is requested from it?
2. It defines some DS components (does the immediate flag matter here)?
What I observed is that Equinox does actually auto-start the bundle once it has the Bundle Header Bundle-ActivationPolicy: lazy being set, which feels wrong to me, as that bundle header should IMHO only defer starting, but in fact without it (i.e. default eager activation) the bundle won’t be started at all.
Thanks in advance for your PoV on this matter
Konrad
_______________________________________________
osgi-users mailing list
osgi-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/osgi-users
--
Jürgen Albert
CEO
Chair Eclipse OSGi Working Group Steering Committee
Data In Motion Consulting GmbH
Kahlaische Str. 4
07745 Jena
Mobil: +49 157-72521634
E-Mail: j.albert@xxxxxxxxxxxxxxxWeb: www.datainmotion.de
XING: https://www.xing.com/profile/Juergen_Albert5
LinkedIn: https://www.linkedin.com/in/juergen-albert-6a1796/
Rechtliches
Jena HBR 513025
_______________________________________________
osgi-users mailing list
osgi-users@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/osgi-users
