Karaf
  1. Karaf
  2. KARAF-1245

blueprint deployer and spring deployer should get started before features.core bundle

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      When org.apache.karaf.features.core bundle is up, it will load features descriptors and try install features, however if the features descriptor has bundle like
      <bundle>blueprint:file:etc/some-blueprint.xml</bundle>, we need blueprint url handler available in the OSGi container, so we need blueprint deployer and spring deployer get started before features.core bundle

        Activity

        Freeman Fang created issue -
        Freeman Fang made changes -
        Field Original Value New Value
        Status Open [ 1 ] In Progress [ 3 ]
        Freeman Fang made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Fix Version/s 2.2.6 [ 12319142 ]
        Resolution Fixed [ 1 ]
        Hide
        Jean-Baptiste Onofré added a comment -

        Thanks Freeman.

        Let me check if we are in the same situation on trunk for Karaf 3.0.0.

        Show
        Jean-Baptiste Onofré added a comment - Thanks Freeman. Let me check if we are in the same situation on trunk for Karaf 3.0.0.
        Jean-Baptiste Onofré made changes -
        Resolution Fixed [ 1 ]
        Status Resolved [ 5 ] Reopened [ 4 ]
        Assignee Freeman Fang [ ffang ] Jean-Baptiste Onofré [ jbonofre ]
        Hide
        Freeman Fang added a comment -

        Hi JB,

        On Karaf 3.0, the blueprint/spring deployer isn't in startup.properties, they're in deployer feature description, so unless we also pull blueprint/spring deployer bundles into startup.properties, there's no way we can guarantee that they get started before features.core bundle.
        I'm +1 to put blueprint/spring deployer bundles into startup.properties, it's easier for end user when they have features which need blueprint/spring url handler.

        Freeman

        Show
        Freeman Fang added a comment - Hi JB, On Karaf 3.0, the blueprint/spring deployer isn't in startup.properties, they're in deployer feature description, so unless we also pull blueprint/spring deployer bundles into startup.properties, there's no way we can guarantee that they get started before features.core bundle. I'm +1 to put blueprint/spring deployer bundles into startup.properties, it's easier for end user when they have features which need blueprint/spring url handler. Freeman
        Hide
        Jean-Baptiste Onofré added a comment -

        Even if the blueprint and spring deployers are not in the startup.properties, they are started after the features core on trunk:

        karaf@root> la|grep -i deployer
        [ 43] [Active ] [Created ] [ 30] Apache Karaf :: Deployer :: Blueprint (3.0.0.SNAPSHOT)
        [ 44] [Active ] [Created ] [ 30] Apache Karaf :: Deployer :: Features (3.0.0.SNAPSHOT)
        [ 45] [Active ] [Created ] [ 30] Apache Karaf :: Deployer :: Wrap Non OSGi Jar (3.0.0.SNAPSHOT)
        karaf@root> la|grep -i feature
        [ 20] [Active ] [Created ] [ 25] Apache Karaf :: Features :: Core (3.0.0.SNAPSHOT)

        I don't think it's required to put the deployers in the startup.properties, but we should update the start-level to 24 in order to start them before the features core bundle.

        I do it

        Show
        Jean-Baptiste Onofré added a comment - Even if the blueprint and spring deployers are not in the startup.properties, they are started after the features core on trunk: karaf@root> la|grep -i deployer [ 43] [Active ] [Created ] [ 30] Apache Karaf :: Deployer :: Blueprint (3.0.0.SNAPSHOT) [ 44] [Active ] [Created ] [ 30] Apache Karaf :: Deployer :: Features (3.0.0.SNAPSHOT) [ 45] [Active ] [Created ] [ 30] Apache Karaf :: Deployer :: Wrap Non OSGi Jar (3.0.0.SNAPSHOT) karaf@root> la|grep -i feature [ 20] [Active ] [Created ] [ 25] Apache Karaf :: Features :: Core (3.0.0.SNAPSHOT) I don't think it's required to put the deployers in the startup.properties, but we should update the start-level to 24 in order to start them before the features core bundle. I do it
        Hide
        Jean-Baptiste Onofré added a comment -

        Nevermind, the deployers should be in the startup.properties, else the features.core will always be started before.

        I move the deployers into the startup.properties.

        Show
        Jean-Baptiste Onofré added a comment - Nevermind, the deployers should be in the startup.properties, else the features.core will always be started before. I move the deployers into the startup.properties.
        Jean-Baptiste Onofré made changes -
        Fix Version/s 3.0.0 [ 12316040 ]
        Jean-Baptiste Onofré made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Jamie goodyear made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Hide
        Ioannis Canellos added a comment -

        I am reopening the issue, because I feel that the features service should not depend on deployers of any short.

        Moreover, the current solution may solve the problem for blueprint and spring url handlers, but still doesn't address the case where the user wants to use a custom url handler.

        Show
        Ioannis Canellos added a comment - I am reopening the issue, because I feel that the features service should not depend on deployers of any short. Moreover, the current solution may solve the problem for blueprint and spring url handlers, but still doesn't address the case where the user wants to use a custom url handler.
        Ioannis Canellos made changes -
        Resolution Fixed [ 1 ]
        Status Closed [ 6 ] Reopened [ 4 ]
        Assignee Jean-Baptiste Onofré [ jbonofre ] Ioannis Canellos [ iocanel ]
        Hide
        Christian Schneider added a comment -

        I think the feature install now waits for some time for missing url handlers. Does this fix the problem? I am also working on parallelizing the install of bundles. This will help if the url handler appear after a bundle they should install. See kARAf-608. I will explain what I have in mind there shortly.

        Show
        Christian Schneider added a comment - I think the feature install now waits for some time for missing url handlers. Does this fix the problem? I am also working on parallelizing the install of bundles. This will help if the url handler appear after a bundle they should install. See kARAf-608. I will explain what I have in mind there shortly.
        Hide
        Ioannis Canellos added a comment -

        I think that using a service tracker to wait for the handler does solve the problem (the way it works now).

        Show
        Ioannis Canellos added a comment - I think that using a service tracker to wait for the handler does solve the problem (the way it works now).
        Hide
        Christian Schneider added a comment -

        Yes .. but then we depend on the handlers .. I would like to find a solution that can work with unknown handlers too. Basically the idea is to first load bundles that do not need the handlers. We then need to start at least the bundles with the handlers before starting the rest. The problem is that there is no way to see if a bundle contains a handler from the outside. So I am not sure how to achieve it.

        Show
        Christian Schneider added a comment - Yes .. but then we depend on the handlers .. I would like to find a solution that can work with unknown handlers too. Basically the idea is to first load bundles that do not need the handlers. We then need to start at least the bundles with the handlers before starting the rest. The problem is that there is no way to see if a bundle contains a handler from the outside. So I am not sure how to achieve it.
        Christian Schneider made changes -
        Fix Version/s 3.1.0 [ 12316946 ]
        Christian Schneider made changes -
        Fix Version/s 3.1.0 [ 12316946 ]
        Christian Schneider made changes -
        Fix Version/s 3.1.0 [ 12316946 ]
        Fix Version/s 3.0.0 [ 12316040 ]
        Jean-Baptiste Onofré made changes -
        Fix Version/s 4.0.0.M3 [ 12316946 ]
        Fix Version/s 2.2.6 [ 12319142 ]
        Hide
        Jean-Baptiste Onofré added a comment -

        Now fixed on K3/K4.

        Show
        Jean-Baptiste Onofré added a comment - Now fixed on K3/K4.
        Jean-Baptiste Onofré made changes -
        Status Reopened [ 4 ] Resolved [ 5 ]
        Resolution Won't Fix [ 2 ]
        Transition Time In Source Status Execution Times Last Executer Last Execution Date
        Open Open In Progress In Progress
        8s 1 Freeman Fang 02/Mar/12 08:51
        In Progress In Progress Resolved Resolved
        6d 22h 14m 1 Freeman Fang 09/Mar/12 07:05
        Resolved Resolved Reopened Reopened
        30m 8s 1 Jean-Baptiste Onofré 09/Mar/12 07:35
        Resolved Resolved Closed Closed
        49d 14h 13m 1 Jamie goodyear 28/Apr/12 00:05
        Closed Closed Reopened Reopened
        136d 16h 18m 1 Ioannis Canellos 11/Sep/12 16:23
        Reopened Reopened Resolved Resolved
        988d 21h 56m 2 Jean-Baptiste Onofré Thursday 13:04

          People

          • Assignee:
            Ioannis Canellos
            Reporter:
            Freeman Fang
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development