dm Server
  1. dm Server
  2. DMS-1763

Multiple scoped plans that reference the same bundle do not working under dm 2.0.0M5

    Details

    • Type: Defect Defect
    • Status: Done Done
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 2.0.0.M5
    • Fix Version/s: Sprint 12, 2.0.0.M6, 2.0.0.RELEASE
    • Component/s: None
    • Labels:
      None
    • Environment:

      RHEL 5,JDK 6.0

      Description

      When two scoped plans refer to same bundles (exposing a osgi-service ),the deployment of second plan fails due to unavailability of the service

        Activity

        Hide
        Andy Wilkinson added a comment -

        Thanks, Vishal.

        I've tried to reproduce the problem using the zip file that you provided, but have been unable to do so. I built the four bundles, placced them in repository/usr and then copied the two plans into pickup. This produced the following, expected, output:

        [2009-10-20 17:39:35.751] fs-watcher                   <HD0001I> Processing 'INITIAL' event for file 'MyPlan.plan'. 
        [2009-10-20 17:39:35.849] fs-watcher                   <DE0056I> Installing plan 'multi-artifact.plan' version '1.0.0'. 
        [2009-10-20 17:39:36.058] fs-watcher                   <DE0057I> Installed bundle 'BundleOneForPlan' version '1.0.0'. 
        [2009-10-20 17:39:36.087] fs-watcher                   <DE0057I> Installed bundle 'BundleTwoForPlan' version '1.0.0'. 
        [2009-10-20 17:39:36.119] fs-watcher                   <DE0057I> Installed bundle 'multi-artifact.plan-synthetic.context' version '1.0.0'. 
        [2009-10-20 17:39:36.138] fs-watcher                   <DE0057I> Installed plan 'multi-artifact.plan' version '1.0.0'. 
        [2009-10-20 17:39:36.311] fs-watcher                   <DE0059I> Starting plan 'multi-artifact.plan' version '1.0.0'. 
        [2009-10-20 17:39:36.327] fs-watcher                   <DE0059I> Starting bundle 'BundleOneForPlan' version '1.0.0'. 
        [2009-10-20 17:39:36.387] fs-watcher                   <DE0059I> Starting bundle 'BundleTwoForPlan' version '1.0.0'. 
        [2009-10-20 17:39:36.468] fs-watcher                   <DE0059I> Starting bundle 'multi-artifact.plan-synthetic.context' version '1.0.0'. 
        [2009-10-20 17:39:36.523] fs-watcher                   <DE0060I> Started bundle 'multi-artifact.plan-synthetic.context' version '1.0.0'. 
        [2009-10-20 17:39:36.665] Thread-3                     <DE0060I> Started bundle 'BundleOneForPlan' version '1.0.0'. 
        [2009-10-20 17:39:36.696] fs-watcher                   <HD0001I> Processing 'INITIAL' event for file 'MyPlanTwo.plan'. 
        [2009-10-20 17:39:36.753] Thread-3                     <DE0060I> Started bundle 'BundleTwoForPlan' version '1.0.0'. 
        [2009-10-20 17:39:36.769] Thread-3                     <DE0060I> Started plan 'multi-artifact.plan' version '1.0.0'. 
        [2009-10-20 17:39:36.841] fs-watcher                   <DE0056I> Installing plan 'multi-artifact-two.plan' version '1.0.0'. 
        [2009-10-20 17:39:37.152] fs-watcher                   <DE0057I> Installed bundle 'BundleOneForPlan' version '1.0.0'. 
        [2009-10-20 17:39:37.190] fs-watcher                   <DE0057I> Installed bundle 'BundleTwoTwoForPlan' version '1.0.0'. 
        [2009-10-20 17:39:37.221] fs-watcher                   <DE0057I> Installed bundle 'multi-artifact-two.plan-synthetic.context' version '1.0.0'. 
        [2009-10-20 17:39:37.244] fs-watcher                   <DE0057I> Installed plan 'multi-artifact-two.plan' version '1.0.0'. 
        [2009-10-20 17:39:37.381] fs-watcher                   <DE0059I> Starting plan 'multi-artifact-two.plan' version '1.0.0'. 
        [2009-10-20 17:39:37.494] fs-watcher                   <DE0060I> Started bundle 'BundleOneForPlan' version '1.0.0'. 
        

        If you would like me to investigate further, can you please attach the compiled, ready packaged bundles, rather than the source code so that I can be sure I'm using the exact some artifacts as you.

        Thanks,
        Andy

        Show
        Andy Wilkinson added a comment - Thanks, Vishal. I've tried to reproduce the problem using the zip file that you provided, but have been unable to do so. I built the four bundles, placced them in repository/usr and then copied the two plans into pickup. This produced the following, expected, output: [2009-10-20 17:39:35.751] fs-watcher <HD0001I> Processing 'INITIAL' event for file 'MyPlan.plan'. [2009-10-20 17:39:35.849] fs-watcher <DE0056I> Installing plan 'multi-artifact.plan' version '1.0.0'. [2009-10-20 17:39:36.058] fs-watcher <DE0057I> Installed bundle 'BundleOneForPlan' version '1.0.0'. [2009-10-20 17:39:36.087] fs-watcher <DE0057I> Installed bundle 'BundleTwoForPlan' version '1.0.0'. [2009-10-20 17:39:36.119] fs-watcher <DE0057I> Installed bundle 'multi-artifact.plan-synthetic.context' version '1.0.0'. [2009-10-20 17:39:36.138] fs-watcher <DE0057I> Installed plan 'multi-artifact.plan' version '1.0.0'. [2009-10-20 17:39:36.311] fs-watcher <DE0059I> Starting plan 'multi-artifact.plan' version '1.0.0'. [2009-10-20 17:39:36.327] fs-watcher <DE0059I> Starting bundle 'BundleOneForPlan' version '1.0.0'. [2009-10-20 17:39:36.387] fs-watcher <DE0059I> Starting bundle 'BundleTwoForPlan' version '1.0.0'. [2009-10-20 17:39:36.468] fs-watcher <DE0059I> Starting bundle 'multi-artifact.plan-synthetic.context' version '1.0.0'. [2009-10-20 17:39:36.523] fs-watcher <DE0060I> Started bundle 'multi-artifact.plan-synthetic.context' version '1.0.0'. [2009-10-20 17:39:36.665] Thread-3 <DE0060I> Started bundle 'BundleOneForPlan' version '1.0.0'. [2009-10-20 17:39:36.696] fs-watcher <HD0001I> Processing 'INITIAL' event for file 'MyPlanTwo.plan'. [2009-10-20 17:39:36.753] Thread-3 <DE0060I> Started bundle 'BundleTwoForPlan' version '1.0.0'. [2009-10-20 17:39:36.769] Thread-3 <DE0060I> Started plan 'multi-artifact.plan' version '1.0.0'. [2009-10-20 17:39:36.841] fs-watcher <DE0056I> Installing plan 'multi-artifact-two.plan' version '1.0.0'. [2009-10-20 17:39:37.152] fs-watcher <DE0057I> Installed bundle 'BundleOneForPlan' version '1.0.0'. [2009-10-20 17:39:37.190] fs-watcher <DE0057I> Installed bundle 'BundleTwoTwoForPlan' version '1.0.0'. [2009-10-20 17:39:37.221] fs-watcher <DE0057I> Installed bundle 'multi-artifact-two.plan-synthetic.context' version '1.0.0'. [2009-10-20 17:39:37.244] fs-watcher <DE0057I> Installed plan 'multi-artifact-two.plan' version '1.0.0'. [2009-10-20 17:39:37.381] fs-watcher <DE0059I> Starting plan 'multi-artifact-two.plan' version '1.0.0'. [2009-10-20 17:39:37.494] fs-watcher <DE0060I> Started bundle 'BundleOneForPlan' version '1.0.0'. If you would like me to investigate further, can you please attach the compiled, ready packaged bundles, rather than the source code so that I can be sure I'm using the exact some artifacts as you. Thanks, Andy
        Hide
        vishal added a comment -

        Hi Andy,

        This is exactly what i get but ii expected it further to say something like ."Started plan 'multi-artifact-two.plan' version '1.0.0'." for MyPlanTwo.plan as it happened for MyPlan.plan

        And the sysouts from MyActivator and the init methods for beans definations in application context

        regards
        vishal

        Show
        vishal added a comment - Hi Andy, This is exactly what i get but ii expected it further to say something like ."Started plan 'multi-artifact-two.plan' version '1.0.0'." for MyPlanTwo.plan as it happened for MyPlan.plan And the sysouts from MyActivator and the init methods for beans definations in application context regards vishal
        Hide
        Andy Wilkinson added a comment -

        Apologies, it had been a long day yesterday and I mis-read the output. I'll take another look at this today. If possible, I'd still like you to attach your binaries that reproduce the problem.

        Thanks,
        Andy

        Show
        Andy Wilkinson added a comment - Apologies, it had been a long day yesterday and I mis-read the output. I'll take another look at this today. If possible, I'd still like you to attach your binaries that reproduce the problem. Thanks, Andy
        Hide
        vishal added a comment -

        Hi Andy
        I have attached the jar in sample.zip

        Regards
        vishal

        Show
        vishal added a comment - Hi Andy I have attached the jar in sample.zip Regards vishal
        Hide
        Andy Wilkinson added a comment -

        Excellent, thanks!

        Show
        Andy Wilkinson added a comment - Excellent, thanks!
        Hide
        Andy Wilkinson added a comment - - edited

        I've looked into this in some more detail, and have tracked things down a little.

        Each plan contains two bundles, one that is specific to the plan (BundleTwoForPlan and BundleTwoTwoForPlan) and one that is 'shared' (BundleOneForPlan). The problem lies with BundleOneForPlan. Even though the plan is scoped (so two copies of the bundle should be installed) the deployer stages the bundle to the same location for each plan. This means that the same install location is passed to Equinox for each install of BundleOneForPlan and the second install is no-oped (as per the OSGi spec). This means that we end up with MyPlanTwo trying to use BundleOneForPlan from MyPlan which falls apart as the manifest scoping is all wrong. This is the root cause of the problem.

        There's also a secondary issue that we won't see once that first problem is fixed, but we should address it nevertheless:

        Everything resolves successfully in the deployer's side state (as the install mechanism is different) but then fails to resolve in the global state. However we fail to notice this failure. I've tracked this down to the fact that we ignore the return value from PackageAdmin.resolveBundles(). This then breaks a precondition of start processing which is that we expect all bundles that the deployer is trying to start to be resolved. We need to check this return value.

        To summarise, the change that is required to fix this issue:

        • Staging needs to become scope aware so that we get multiple copies of a bundle when its referenced in multiple scoped plans

        And the change that's required to fix the secondary issue:

        • ResolveStage.process() needs to check the return value from PackageAdmin.resolveBundles and throw a DeploymentException if it's false (ideally containing details of the resolution failure).
        Show
        Andy Wilkinson added a comment - - edited I've looked into this in some more detail, and have tracked things down a little. Each plan contains two bundles, one that is specific to the plan (BundleTwoForPlan and BundleTwoTwoForPlan) and one that is 'shared' (BundleOneForPlan). The problem lies with BundleOneForPlan. Even though the plan is scoped (so two copies of the bundle should be installed) the deployer stages the bundle to the same location for each plan. This means that the same install location is passed to Equinox for each install of BundleOneForPlan and the second install is no-oped (as per the OSGi spec). This means that we end up with MyPlanTwo trying to use BundleOneForPlan from MyPlan which falls apart as the manifest scoping is all wrong. This is the root cause of the problem. There's also a secondary issue that we won't see once that first problem is fixed, but we should address it nevertheless: Everything resolves successfully in the deployer's side state (as the install mechanism is different) but then fails to resolve in the global state. However we fail to notice this failure. I've tracked this down to the fact that we ignore the return value from PackageAdmin.resolveBundles(). This then breaks a precondition of start processing which is that we expect all bundles that the deployer is trying to start to be resolved. We need to check this return value. To summarise, the change that is required to fix this issue: Staging needs to become scope aware so that we get multiple copies of a bundle when its referenced in multiple scoped plans And the change that's required to fix the secondary issue: ResolveStage.process() needs to check the return value from PackageAdmin.resolveBundles and throw a DeploymentException if it's false (ideally containing details of the resolution failure).
        Hide
        Andy Wilkinson added a comment -

        Vishal, thanks for raising this issue, you've helped us to find a rather interesting problem.

        You can work around the problem by not referencing the same bundle in multiple scoped plans. My apologies for this as I realise it's rather limiting: we'll fix this issue ASAP.

        Show
        Andy Wilkinson added a comment - Vishal, thanks for raising this issue, you've helped us to find a rather interesting problem. You can work around the problem by not referencing the same bundle in multiple scoped plans. My apologies for this as I realise it's rather limiting: we'll fix this issue ASAP.
        Hide
        Glyn Normington (c) added a comment -

        I have fixed the problem in the kernel and have added diagnostics for the secondary issue. These fixes are push to the kernel git repository and are awaiting a "ripple" to integrate them into dm Server ready for a nightly build.

        Show
        Glyn Normington (c) added a comment - I have fixed the problem in the kernel and have added diagnostics for the secondary issue. These fixes are push to the kernel git repository and are awaiting a "ripple" to integrate them into dm Server ready for a nightly build.

          People

          • Assignee:
            Glyn Normington (c)
            Reporter:
            vishal
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              First Response Date:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0h
              0h
              Logged:
              Time Spent - 2.5h
              2.5h