ServiceMix
  1. ServiceMix
  2. SM-2301

Problem installing activiti feature after upgrade to ActiveMQ 5.9.1

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.0.4, 5.1.2, 5.2.0
    • Component/s: assemblies
    • Labels:
      None

      Description

      I'm trying to perform the upgrade and getting following exception when trying to install the activiti feature with refresh disabled (-r). It is not possible to install with refresh due to SM-2287

      Error executing command: Could not start bundle mvn:org.apache.servicemix.activiti/org.apache.servicemix.activiti.config/5.1.0-SNAPSHOT in feature(s) activiti-5.15.1: Uses constraint violation. Unable to resolve bundle revision org.activiti.engine [171.0] because it is exposed to package 'org.joda.time.format' from bundle revisions org.apache.servicemix.bundles.joda-time [167.0] and joda-time [101.0] via two dependency chains.
      
      Chain 1:
        org.activiti.engine [171.0]
          import: (&(osgi.wiring.package=org.joda.time.format)(version>=2.1.0)(!(version>=3.0.0)))
           |
          export: osgi.wiring.package=org.joda.time.format
        org.apache.servicemix.bundles.joda-time [167.0]
      
      Chain 2:
        org.activiti.engine [171.0]
          import: (&(osgi.wiring.package=org.drools.runtime)(version>=5.5.0)(!(version>=6.0.0)))
           |
          export: osgi.wiring.package=org.drools.runtime; uses:=com.thoughtworks.xstream.annotations
        org.apache.servicemix.bundles.drools [164.0]
          import: (osgi.wiring.package=com.thoughtworks.xstream.annotations)
           |
          export: osgi.wiring.package=com.thoughtworks.xstream.annotations; uses:=org.joda.time.format
        org.apache.servicemix.bundles.xstream [93.0]
          import: (&(osgi.wiring.package=org.joda.time.format)(version>=1.6.0)(!(version>=3.0.0)))
           |
          export: osgi.wiring.package=org.joda.time.format
        joda-time [101.0]
      
      

      The same problem occurs in Activiti example itests.

        Issue Links

          Activity

          Hide
          Gert Vanthienen added a comment -

          Added a workaround for servicemix-5.1.x in https://git-wip-us.apache.org/repos/asf?p=servicemix.git;a=commit;h=3979908d1ae07bdebd2c3ace2d2e5ca521e18654

          We never downgraded the Karaf version for 6.0.0 so things should still be OK there.

          Show
          Gert Vanthienen added a comment - Added a workaround for servicemix-5.1.x in https://git-wip-us.apache.org/repos/asf?p=servicemix.git;a=commit;h=3979908d1ae07bdebd2c3ace2d2e5ca521e18654 We never downgraded the Karaf version for 6.0.0 so things should still be OK there.
          Hide
          Gert Vanthienen added a comment - - edited

          Aligning versions of joda-time across projects would be the best solution in the longer term. For now, it looks like adding joda-time to the startup.properties fixes the issue as well. When the bundle is installed before everything else, the xstream bundle gets wired to the newer version of joda-time, avoiding the classloading issue.

          Show
          Gert Vanthienen added a comment - - edited Aligning versions of joda-time across projects would be the best solution in the longer term. For now, it looks like adding joda-time to the startup.properties fixes the issue as well. When the bundle is installed before everything else, the xstream bundle gets wired to the newer version of joda-time , avoiding the classloading issue.
          Hide
          Krzysztof Sobkowiak added a comment -

          The best fix would be upgrade the version of joda-time bundle to 2.1 in activemq feature as only org.apache.servicemix.bundles.xstream seems to use this and supports 2.1 too. We have to check whether Camel and CXF use joda-time too and in which version.

          Show
          Krzysztof Sobkowiak added a comment - The best fix would be upgrade the version of joda-time bundle to 2.1 in activemq feature as only org.apache.servicemix.bundles.xstream seems to use this and supports 2.1 too. We have to check whether Camel and CXF use joda-time too and in which version.
          Hide
          Krzysztof Sobkowiak added a comment - - edited

          Retested with 5.1.0 after downgrade to Karaf 2.3.4. The problem exists again. Probably caused by not supported option respectStartLvlDuringFeatureStartup=true – the joda feature not always is installed before activiti} and {{activemq features. Reopening to give some time to investigate

          Show
          Krzysztof Sobkowiak added a comment - - edited Retested with 5.1.0 after downgrade to Karaf 2.3.4 . The problem exists again. Probably caused by not supported option respectStartLvlDuringFeatureStartup=true – the joda feature not always is installed before activiti} and {{activemq features. Reopening to give some time to investigate
          Show
          Krzysztof Sobkowiak added a comment - Fixed in master – https://git-wip-us.apache.org/repos/asf/servicemix/?p=servicemix.git;a=commit;h=fb557e2629d1fd195eb32cde1f124b2c134f7cfc
          Show
          Krzysztof Sobkowiak added a comment - Fixed in servicemix-5.1.x – https://git-wip-us.apache.org/repos/asf/servicemix/?p=servicemix.git;a=commit;h=bfeb5ec4cc020fbcc52febcc803ba5be33ce852c
          Hide
          Krzysztof Sobkowiak added a comment -

          I have done a small experiment and found a workaround for this problem. I have created a joda feature containing the org.apache.servicemix.bundles.joda-time which provides the required package in version 2.1 and included it at the beginning of featuresBoot. While booting the package form this feature is wired into org.apache.servicemix.bundles.xstream and activiti feature can be installed with no problem because org.apache.servicemix.bundles.xstream imports already the correct package.

          Show
          Krzysztof Sobkowiak added a comment - I have done a small experiment and found a workaround for this problem. I have created a joda feature containing the org.apache.servicemix.bundles.joda-time which provides the required package in version 2.1 and included it at the beginning of featuresBoot . While booting the package form this feature is wired into org.apache.servicemix.bundles.xstream and activiti feature can be installed with no problem because org.apache.servicemix.bundles.xstream imports already the correct package.
          Hide
          Krzysztof Sobkowiak added a comment -

          The org.activiti.engine imports org.joda.time.format package It can be resolved from org.apache.servicemix.bundles.joda-time bundle or from joda-time (via other path – org.apache.servicemix.bundles.drools and org.apache.servicemix.bundles.xstream.

          Because the org.apache.servicemix.bundles.xstream bundle imports optional org.joda.time.format in version [1.6.0, 3.0.0) and is installed with activemq feature in featuresBoot the package is resolved with version 1.6.0 from joda-time which is also part of the activemq feature.

          Next when installing the activiti feature, the org.activiti.engine requires the same package with higher version [2.1.0, 3.0.0). With the refresh option we had probably no problem and org.apache.servicemix.bundles.xstream would be probably resolved again with the package from org.apache.servicemix.bundles.joda-time in higher version which is also allowed for org.apache.servicemix.bundles.xstream. But with refresh disabled it doesn't happen and the package can not be correctly wired into org.activiti.engine

          This problem didn't happen with ActiveMQ 5.9.0, because the activemq features includes org.apache.servicemix.bundles.xstream with version 1.3_2 which imports org.joda.time.format with range [0.9,1). Because the import is optional and no bundle provides this package with this version, the package is not wired into org.apache.servicemix.bundles.xstream and org.activiti.engine imports the package from org.apache.servicemix.bundles.joda-time

          ActiveMQ 5.9.1 feature includes org.apache.servicemix.bundles.xstream with version 1.4.7_1 which imports org.joda.time.format with version provided by joda-time which is not compatible with import in org.activiti.engine

          Show
          Krzysztof Sobkowiak added a comment - The org.activiti.engine imports org.joda.time.format package It can be resolved from org.apache.servicemix.bundles.joda-time bundle or from joda-time (via other path – org.apache.servicemix.bundles.drools and org.apache.servicemix.bundles.xstream . Because the org.apache.servicemix.bundles.xstream bundle imports optional org.joda.time.format in version [1.6.0, 3.0.0) and is installed with activemq feature in featuresBoot the package is resolved with version 1.6.0 from joda-time which is also part of the activemq feature. Next when installing the activiti feature, the org.activiti.engine requires the same package with higher version [2.1.0, 3.0.0) . With the refresh option we had probably no problem and org.apache.servicemix.bundles.xstream would be probably resolved again with the package from org.apache.servicemix.bundles.joda-time in higher version which is also allowed for org.apache.servicemix.bundles.xstream . But with refresh disabled it doesn't happen and the package can not be correctly wired into org.activiti.engine This problem didn't happen with ActiveMQ 5.9.0, because the activemq features includes org.apache.servicemix.bundles.xstream with version 1.3_2 which imports org.joda.time.format with range [0.9,1) . Because the import is optional and no bundle provides this package with this version, the package is not wired into org.apache.servicemix.bundles.xstream and org.activiti.engine imports the package from org.apache.servicemix.bundles.joda-time ActiveMQ 5.9.1 feature includes org.apache.servicemix.bundles.xstream with version 1.4.7_1 which imports org.joda.time.format with version provided by joda-time which is not compatible with import in org.activiti.engine

            People

            • Assignee:
              Krzysztof Sobkowiak
              Reporter:
              Krzysztof Sobkowiak
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development