Uploaded image for project: 'Karaf'
  1. Karaf
  2. KARAF-1894

Framework's active start level is set to org.osgi.framework.startlevel.beginning too early when launching Karaf with empty bundle cache

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: 2.2.9, 3.0.0
    • Fix Version/s: 2.2.12, 2.4.0, 3.0.2, 2.3.6
    • Component/s: None
    • Labels:
      None
    • Environment:

      Mac 10.8.2/Oracle JDK 1.6.0_35

      Description

      When launching Karaf 2.2.9 with an empty bundle cache, the framework's active start level is already set to org.osgi.framework.startlevel.beginning before all the boot features have been started. The impact is that bundles can be loaded in the wrong order, and File Install ends up scanning the deploy folder when it's not supposed to.

      This is problematic because we're using boot features to load up our core infrastructure and the deploy folder to host plugins. If we prepackage any plugins with our product with an empty bundle cache, the plugins get installed and started before the core.

      The attached tarball contains a set of 3 bundles that reproduce the symptoms. Simply untar within the apache-karaf-2.2.9 directory.

      In the test tarball, there are 3 bundles that do the same thing. When start() is called, they print out their name and the framework's current start level, then wait for 1 second.

      bundle1 (start-level=60) and bundle2 (start-level=80) are part of a boot feature. However, bundle2 is listed first in the XML. bundle3 is in the deploy directory. File Install is configured so that it doesn't scan until start level 81 (via felix.fileinstall.active.level).

      I'm expecting that the bundles are loaded in this order: bundle1, bundle2, bundle3.

      If I clear the bundle cache and start Karaf, I get the following output:

      [bundle2] 100
      [bundle3] 100
      [bundle1] 100

      This indicates that when bundle2's start() is called, the framework's start level is already set to org.osgi.framework.startlevel.beginning (in this case, 100) before the boot features have started.

      If I run Karaf again without clearing the bundle cache, I get the following:

      [bundle1] 60
      [bundle2] 80
      [bundle3] 80

      This is better, but felix.fileinstall.active.level is set to 81, so bundle3 should not be starting at start level 80. This is probably a separate issue.

      1. slbug.tar-3.0.gz
        7 kB
        Jason Montojo
      2. slbug.tar.gz
        7 kB
        Jason Montojo

        Activity

        Hide
        jmontojo Jason Montojo added a comment -

        Tarball containing overlay that reproduces described issue. Simply untar from within apache-karaf-2.2.9 folder.

        Show
        jmontojo Jason Montojo added a comment - Tarball containing overlay that reproduces described issue. Simply untar from within apache-karaf-2.2.9 folder.
        Hide
        gnt Guillaume Nodet added a comment -

        Could you try with a 3.0 snapshot ? I think things are slightly different and boot features may be installed synchronously at a lower start level.

        Show
        gnt Guillaume Nodet added a comment - Could you try with a 3.0 snapshot ? I think things are slightly different and boot features may be installed synchronously at a lower start level.
        Hide
        jmontojo Jason Montojo added a comment -

        The problem persists with apache-karaf-3.0.0-20121003.181714-621.tar.gz.

        With a clear bundle cache, I see this output.

        [bundle3] 100
        [bundle2] 100
        [bundle1] 100

        After restarting Karaf, I get this:

        [bundle1] 60
        [bundle2] 80
        [bundle3] 80

        But I'm expecting to see this, whether or not the bundle cache is empty:

        [bundle1] 60
        [bundle2] 80
        [bundle3] 81 <-- or anything higher than 81

        Show
        jmontojo Jason Montojo added a comment - The problem persists with apache-karaf-3.0.0-20121003.181714-621.tar.gz. With a clear bundle cache, I see this output. [bundle3] 100 [bundle2] 100 [bundle1] 100 After restarting Karaf, I get this: [bundle1] 60 [bundle2] 80 [bundle3] 80 But I'm expecting to see this, whether or not the bundle cache is empty: [bundle1] 60 [bundle2] 80 [bundle3] 81 <-- or anything higher than 81
        Hide
        jmontojo Jason Montojo added a comment -

        Tarball containing overlay for 3.0.0-SNAPSHOT stream

        Show
        jmontojo Jason Montojo added a comment - Tarball containing overlay for 3.0.0-SNAPSHOT stream
        Hide
        jbonofre Jean-Baptiste Onofré added a comment -

        The deploy folder is handled by Felix fileinstall.

        The issue is that fileinstall would need additional meta-data to know the start-level of a bundle (it uses its own start level by default).

        What you can do is to define several fileinstall instances with different folders and start-level.

        For instance, you can configure (via etc/config.properties) to have:

        • deploy
        • deploy/81
        • deploy/90
        • ...

        Each folder has its own fileinstall configuration with different start level.

        Show
        jbonofre Jean-Baptiste Onofré added a comment - The deploy folder is handled by Felix fileinstall. The issue is that fileinstall would need additional meta-data to know the start-level of a bundle (it uses its own start level by default). What you can do is to define several fileinstall instances with different folders and start-level. For instance, you can configure (via etc/config.properties) to have: deploy deploy/81 deploy/90 ... Each folder has its own fileinstall configuration with different start level.
        Hide
        jbonofre Jean-Baptiste Onofré added a comment -

        Anyway, it sounds like a bug in Fileinstall. I will take a look in Felix Fileinstall.

        Show
        jbonofre Jean-Baptiste Onofré added a comment - Anyway, it sounds like a bug in Fileinstall. I will take a look in Felix Fileinstall.
        Hide
        jbonofre Jean-Baptiste Onofré added a comment -

        After checking on Felix Fileinstall, the property felix.fileinstall.active.level is for fileinstall itself (not the bundles that it deploys): the purpose is to disable fileinstall while the OSGi framework start level is too low.

        To define the start level of the bundles, you have to use the felix.fileinstall.start.level property: it's the start level given by FileInstall to the bundles that it deploys.

        The thing that I want to check is if the FeaturesService installs the features in a synchronous mode or not.

        Another thing to use is Blueprint in synchronous mode (for Blueprint bundles).

        In the mean time, could you try, in etc/config.properties, to set the following property:

        org.apache.aries.blueprint.synchronous=true

        Show
        jbonofre Jean-Baptiste Onofré added a comment - After checking on Felix Fileinstall, the property felix.fileinstall.active.level is for fileinstall itself (not the bundles that it deploys): the purpose is to disable fileinstall while the OSGi framework start level is too low. To define the start level of the bundles, you have to use the felix.fileinstall.start.level property: it's the start level given by FileInstall to the bundles that it deploys. The thing that I want to check is if the FeaturesService installs the features in a synchronous mode or not. Another thing to use is Blueprint in synchronous mode (for Blueprint bundles). In the mean time, could you try, in etc/config.properties, to set the following property: org.apache.aries.blueprint.synchronous=true
        Hide
        shrishs Shrish Srivastava added a comment -

        I recreated the whole scenarion and found that if we define the bundle in start.properties ,things works in the expected order.

        Show
        shrishs Shrish Srivastava added a comment - I recreated the whole scenarion and found that if we define the bundle in start.properties ,things works in the expected order.
        Hide
        jbonofre Jean-Baptiste Onofré added a comment -

        I guess you talk about etc/startup.properties. But startup.properties is different: it's the definition of the system bundles.

        In the startup.properties you explicitly define the bundle location and the start level. It's not the same purpose as in deploy (especially in term of hotdeployment).
        Gathering all bundles in a bootFeatures is fine as well (as you can define dependencies between features).

        I don't mind that you define the bundles in etc/startup.properties, but in that case you create a kind of "custom Karaf distribution" (which can make sense).

        Show
        jbonofre Jean-Baptiste Onofré added a comment - I guess you talk about etc/startup.properties. But startup.properties is different: it's the definition of the system bundles. In the startup.properties you explicitly define the bundle location and the start level. It's not the same purpose as in deploy (especially in term of hotdeployment). Gathering all bundles in a bootFeatures is fine as well (as you can define dependencies between features). I don't mind that you define the bundles in etc/startup.properties, but in that case you create a kind of "custom Karaf distribution" (which can make sense).
        Hide
        shrishs Shrish Srivastava added a comment -

        Just to make thing more clearer from my side .I have created Bundle1 and Bundle 2 and put them in Karaf system folder and made the entry in etc/startup.properties.I have deployed Bundle3 in karaf deploy folder .And the Bundle3 is getting deployed as the last bundle.

        Show
        shrishs Shrish Srivastava added a comment - Just to make thing more clearer from my side .I have created Bundle1 and Bundle 2 and put them in Karaf system folder and made the entry in etc/startup.properties.I have deployed Bundle3 in karaf deploy folder .And the Bundle3 is getting deployed as the last bundle.
        Hide
        jbonofre Jean-Baptiste Onofré added a comment -

        Correct and it's normal: the startup.properties define the core bundles started before all others, including Fileinstall itself (you can see that felix.fileinstall is define in the startup.properties itself).

        Show
        jbonofre Jean-Baptiste Onofré added a comment - Correct and it's normal: the startup.properties define the core bundles started before all others, including Fileinstall itself (you can see that felix.fileinstall is define in the startup.properties itself).
        Hide
        jmontojo Jason Montojo added a comment -

        Thanks for the feedback! I tried setting felix.fileinstall.start.level to 100 on Karaf 2.2.9 but it did not affect the start order using an empty bundle cache.

        My main concern is that the boot feature bundles (bundle1 and bundle2) are being loaded in the wrong order. The load order seems to depend on their ordering in the features.xml file rather than their declared start-level.

        Show
        jmontojo Jason Montojo added a comment - Thanks for the feedback! I tried setting felix.fileinstall.start.level to 100 on Karaf 2.2.9 but it did not affect the start order using an empty bundle cache. My main concern is that the boot feature bundles (bundle1 and bundle2) are being loaded in the wrong order. The load order seems to depend on their ordering in the features.xml file rather than their declared start-level.
        Hide
        jbonofre Jean-Baptiste Onofré added a comment -

        Bundles in the same feature are deployed in the order defined in the features XML.

        For instance:

        <feature>
        <bundle>2</bundle>
        <bundle>1</bundle>
        </feature>

        Bundle 2 will be deployed and started before bundle 1. If you use start-level on the feature XML (<bundle start-level=".."/>), it will respect the start level, but only starting from 2.3.1.

        If you want to "force" the deployment/startup order, just define two features:

        <feature name="1">
        <bundle>1</bundle>
        </feature>

        <feature name="2">
        <feature>1</feature>
        <bundle>2</bundle>
        </feature>

        2 is the boot feature and it will deploy 1 before 2.

        Show
        jbonofre Jean-Baptiste Onofré added a comment - Bundles in the same feature are deployed in the order defined in the features XML. For instance: <feature> <bundle>2</bundle> <bundle>1</bundle> </feature> Bundle 2 will be deployed and started before bundle 1. If you use start-level on the feature XML (<bundle start-level=".."/>), it will respect the start level, but only starting from 2.3.1. If you want to "force" the deployment/startup order, just define two features: <feature name="1"> <bundle>1</bundle> </feature> <feature name="2"> <feature>1</feature> <bundle>2</bundle> </feature> 2 is the boot feature and it will deploy 1 before 2.
        Hide
        shrishs Shrish Srivastava added a comment -

        I am out of office today and will be back on 2nd December.Please contact kkrishnan@talend.com or afuchs@talend.com for any urgent matter.

        Show
        shrishs Shrish Srivastava added a comment - I am out of office today and will be back on 2nd December.Please contact kkrishnan@talend.com or afuchs@talend.com for any urgent matter.

          People

          • Assignee:
            jbonofre Jean-Baptiste Onofré
            Reporter:
            jmontojo Jason Montojo
          • Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development