Montag, 5. März 2012

Start buggy lazy Bundles

Yesterday I push to github a simple bundle, which I use in bnd and bndtools to activate buggy lazy bundles.

What is a buggy lazy Bundle?
Sometimes I have bundles with a Bundle-ActivationPolicy header, which is set to lazy. But no other bundle in the application loads classes from this bundle or use a service e.g. via DS from this bundle. In some cases the lazy bundle didn’t export anything.

When you like to use such lazy bundles, then this bundle must be start by hand. Examples are the Eclipse  ECF bundles. To use the ECF bundles (see also ticket ID-373475) some of the bundles must be start by hand because of the Bundle-ActivationPolicy header lazy. I think these are buggy bundles and the Bundle-ActivationPolicy header should be removed from the manifests.

When you use lazy bundles then this bundles should automatically started by the OSGi framework, when some other bundle in the application need the functionally of the lazy bundle. Think about before you use the Bundle-ActivationPolicy lazy. Only use lazy bundles when the OSGi framework could detect that some other bundle would like to use functionally which the lazy bundle provides.

Examples use lazy bundles when the bundle exports packages with classes and only when some other bundle loads a class from these exported packages the bundle should be in state active. Or when the bundle provides an OSGi service via DS and the bundle should only be in state active when some other bundle would like to use this service. So be careful with using the Bundle-ActivationPolicy header.

More about lazy activation bundle see the OSGi Alliance web site here.

Handling buggy lazy Bundles in Bnd
When you like to use a buggy lazy bundle with bnd or bndtools the bundle must be started by hand. For this I create a simple bundle, which I call “Start lazy Bundles”. The bundle implements an extender pattern which watch for starting bundles. When the starting bundle has a Bundle-ActivationPolicy lazy and the bundle symbolic name is set in a system property the “Start lazy Bundles” bundle try’s to start the bundle.

More details see the Github project:


  1. Please open a bug at against ECF stating the bundles you consider buggy.

  2. raised a bug at against ECF about using Bundle-ActivationPolicy lazy in the ECF bundles see

  3. You should start your required bundles in config.ini or with a property like this:


    Lazy activation policy is an important aspect of scalable osgi applications and not just a corner case. Imagine what would happen if all my 1500 eclipse plugins would start automatically: I could drink more coffee ;) Besides, removing lazy activation policy does not start the bundle.

    "Examples are the eclipse equinox ECF bundles."
    ECF bundles do export so they do not fall into your category "buggy" please make that more clear (they are also not equinox bundles)

    "To use the ECF bundles (see also ticket ID-373475) some of the bundles must be start by hand because of the Bundle-ActivationPolicy header lazy"
    That is not true. Bundles always need to be started by hand or by configuration. Lazy activation is a great method to postpone bundle activation (i.e. go through the bundle lifecycle) until they are needed. Without lazy activation you could just use the bundle as a library without it ever going into the bundle lifecycle. Bundles only start if you or the framework starts them, either by framework, by console (manually) or with lazy activation policy..

    From page 224:
    "Note that nothing happens until we have started both the SCR (DS) bundle and our
    own bundle. The SCR bundle need to be active for it to do anything, and our
    bundle needs to be active because SCR ignores bundles in any other state"

    I believe from a quick glance that your github extender bundle starts bundles by passing bundle names via properties. This is default osgi functionality and you should use that instead. Take a look at this section of equinox.

    I do agree that selectively starting bundles can be a pain and that bundles without exporting classes can be consider "buggy". However, I don't think this is the case with ECF.

    lazy activation is an excellent way of providing postponed lifecyle activation. This makes it possible for "expensive bundles" (the ones with a lot of initialization time) to still play along in big osgi applications without sacrificing scalability.


    1. I fixed the error in the post, yes the ECF bundles are no equinox bundles sorry for this mistake.

      I absolute agree you don't want remove the Bundle-ActivationPolicy lazy from all eclipse OSGi bundles and also not from all ECF bundles.

      I don't use the equinox config.ini and the ECF bundles I think should also work when use only the standard OSGi APIs to install and start bundles. The pseudo code shows how the bundles are installed and started:

      Bundle b = bundleContext.install(...);

      The comment from Neils free OSGi book:
      "Note that nothing happens until we have started both the SCR (DS) bundle and our
      own bundle. The SCR bundle need to be active for it to do anything, and our
      bundle needs to be active because SCR ignores bundles in any other state"
      Is wrong the bundle could also be in the state starting, this is nor right see the OSGi Compedium specification for that. You could also try it in eclipse and this is also how the eclipse registry bundle and DS implementation works and activate bundles.

      See the “112 Declarative Services Specification version 1.1” on page 329:

      “When SCR is implemented as a bundle, any component configurations activated by SCR must be deactivated when the SCR bundle is stopped. When the SCR bundle is started, it must process any components that are declared in bundles that are started. This includes bundles which are started and are awaiting lazy activation.”

      So I believe the right OSGi way for a bundle with the header Bundle-ActivationPolicy lazy is there must be a possible event to start the bundle by the OSGi framework e.g. when you switch in Eclipse into another perspective then a lazy bundle which provides a view for this perspective will be started by the OSGi framework because the classes will be loaded e.g. via DS or via the eclipse registry.
      I think the header should be removed from the ECF bundles which notes that a remote service is offered (discoverd). So this is the initial event to start the ECF bundles on the consumer site of a remote service application.

      Please see also my comment on the ticket.

    2. Wim, you're right that being lazy in some way is important in any large application, including Eclipse. You're wrong about how this is achieved. Bundle-ActivationPolicy lazy is only required for the very strange corner case of a bundle that wants to have a BundleActivator but NOT execute that activator until another class is loaded from the bundle.

      In fact we CAN start all 1500 bundles in an application automatically, and not have to drink lots of extra coffee. As long as those bundles have no Activators, the activation is merely a matter of setting a flag... the framework doesn't even need to create a ClassLoader for the bundle. Once the active flag is set, DS can register the services declared by the bundle and those services can be instantiated on-demand... i.e. lazily.

      Bundle-ActivationPolicy:lazy does have its uses but they are very thin, and unfortunately very few developers actually understand what it means.

      Regarding those passages in my book... Christian is right, and I was wrong. Actually I think I may have been right when I wrote it, but the Bundle-ActivationPolicy:lazy behaviour hadn't been specified yet, it was still just an Eclipse-specific extension.

  4. Dieser Kommentar wurde vom Autor entfernt.

  5. (hit enter too soon on previous post and now I lost it)

    I believe I was talking about "expensive" bundles. And indeed, the lazyness of Eclipse is also achieved by avoiding class loading through plugin.xml information.

    But if we go back to the main problem of this post. How would removing lazy-activation solve this problem? The bundle would still not get started.

    1. @Wim should I restore your lost comment?

      "But if we go back to the main problem of this post. How would removing lazy-activation solve this problem? The bundle would still not get started."

      I do not understand what you're like to say. All my OSGi bundles are active, there is no case were a bundle must be start, in the ECF case the discovery bundles are lazy and do not discover the remote service as a local OSGi service. Because of that my DS component will not be satisfied and is in state unsatisfied. And in the application is no trigger class which could trigger the OSGi framework to start the bundles.

      I think when you use lazy bundles there must be a trigger class which says now I need the features which are provided by the lazy bundle. But when there is now such class and you could not build a bundle which contains such class, then the bundle should not be lazy and every things will work fine.

      If the bundle anyway contains the Bundle-ActivationPolicy lazy, the developer must know that the bundle must anyway be started e.g. in config.ini or via my workaround bundle.

    2. "The bundle would still not get started". Right, but that's the case with Bundle-ActivationPolicy:lazy also. In ALL cases, somebody has to start the bundle; bundles never go from RESOLVED to STARTING automatically.

      The problem is that with B-AP, starting the bundle does nothing. Take out that header, and starting the bundle does something. I prefer the latter ;-)

  6. @christian never mind the previous comment. It was draft anyway.

    Can you attach a zip to the bug with all the bundles in there (you can probably leave out your own bundles if they are closed). Can you also provide the command line arguments that you use to start the fw with?

    If you do we will investigate why ECF's bundle is not started. I need to understand the fine nuances between why your ECF bundle with BAP=lazy is not activated and mine is. I don't see Neils last comment happening. If I start the framework as indicated, the bundle goes through full activation.

    So I'd appreciate the effort.

    1. yes I can attach the bundes to the ticket, also my bundles they are all open source. The ECF bundles are used in a demo project call mars robot. The project we use for the German OSGi Code Camp to learn the OSGi basics and also advanced stuff like OSGi remote services. If you interset in the OSGi Mars Robot please see the project SVN repo

  7. @christian Thanks. I appreciate you use the ECF bundles for that.

  8. Hello Christian, we are still waiting for the attachements of the bundles. It would be great if you could also attach the ECF bundles in their fixed state so that we can patch the bundles for our upcoming maintenance release.

    1. I'm sorry, I will attach the bundles as soon as possible. Hope I will have some free time tonight to attach the bundles. Sorry at the moment I'm really busy.

    2. ECF bundles with some demos are attached to the ticked now.