Uploaded image for project: 'ActiveMQ Classic'
  1. ActiveMQ Classic
  2. AMQ-6301

Embed spring-dm in activemq-osgi to avoid loading spring-dm in Karaf

Details

    • Improvement
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 5.13.0
    • 5.13.4, 5.14.0
    • OSGi/Karaf
    • Patch Available
    • Patch

    Description

      Embed spring-dm in activemq-osgi to avoid loading spring-dm in Karaf

      In commit 3a6d67e8f95320bea91b7c7106173c9b34773bc5, a test was fixed in issue AMQ-4727 by reusing the spring-dm OsgiBundleXmlApplicationContext class inside the ActiveMQServiceFactory managed service factory.

      To satisfy the import packages for activemq-osgi, the 'spring-dm' Karaf feature was added to the main 'activemq-client' feature.

      This is problematic because loading the 'spring-dm' Karaf feature enables the Spring DM deployer. This deployer is unnecessary in environments that rely on Blueprint or CDI wiring and it may unexpectedly activate Spring DM bundles in those environments. Because spring-dm was compiled against older versions of Spring 3.0 and 3.1, it can also cause older versions of Spring features to be loaded into the container.

      To avoid using the ‘spring-dm’ Karaf feature to provide the classes, I propose embedding the spring-dm bundles inside activemq-osgi. Since they are only used as library code to provide the BundleContext when parsing the BrokerService context, they can be embedded safely without any dependency issues.

      This is the root cause of the following issue:

      http://karaf.922171.n3.nabble.com/Karaf-4-0-3-unable-to-start-bundle-activemq-osgi-5-13-0-td4044640.html

      Attachments

        Issue Links

          Activity

            soleger Seth Leger added a comment -

            Embedding spring-dm should fix all of these other issues since they are fundamentally related to Spring version conflicts in Karaf.

            soleger Seth Leger added a comment - Embedding spring-dm should fix all of these other issues since they are fundamentally related to Spring version conflicts in Karaf.
            githubbot ASF GitHub Bot added a comment -

            GitHub user soleger opened a pull request:

            https://github.com/apache/activemq/pull/187

            AMQ-6301: Changed activemq-osgi so that it embeds the spring-dm bundles

            This changes the activemq-osgi bundle so that it inline-embeds the spring-dm bundles which have been used inside the ActiveMQServiceFactory since version 5.13.0.

            To write tests for this, I had to hardcode the Spring versions so that they match the version from the particular version of Karaf that is used by Pax Exam. If somebody has a way to fetch these versions dynamically, that would make it easier to maintain.

            If this could also be merged for inclusion in version 5.13.x, that would be appreciated! Thanks.

            You can merge this pull request into a Git repository by running:

            $ git pull https://github.com/soleger/activemq AMQ-6301

            Alternatively you can review and apply these changes as the patch at:

            https://github.com/apache/activemq/pull/187.patch

            To close this pull request, make a commit to your master/trunk branch
            with (at least) the following in the commit message:

            This closes #187


            commit 91652493d7bf99345b74831ea568f0823f6d612a
            Author: Seth Leger <seth@opennms.org>
            Date: 2016-05-22T21:49:44Z

            AMQ-6301: Changed activemq-osgi so that it embeds the spring-dm bundles
            so that we can avoid loading the spring-dm feature which causes Spring
            version conflicts.


            githubbot ASF GitHub Bot added a comment - GitHub user soleger opened a pull request: https://github.com/apache/activemq/pull/187 AMQ-6301 : Changed activemq-osgi so that it embeds the spring-dm bundles This changes the activemq-osgi bundle so that it inline-embeds the spring-dm bundles which have been used inside the ActiveMQServiceFactory since version 5.13.0. To write tests for this, I had to hardcode the Spring versions so that they match the version from the particular version of Karaf that is used by Pax Exam. If somebody has a way to fetch these versions dynamically, that would make it easier to maintain. If this could also be merged for inclusion in version 5.13.x, that would be appreciated! Thanks. You can merge this pull request into a Git repository by running: $ git pull https://github.com/soleger/activemq AMQ-6301 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/activemq/pull/187.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #187 commit 91652493d7bf99345b74831ea568f0823f6d612a Author: Seth Leger <seth@opennms.org> Date: 2016-05-22T21:49:44Z AMQ-6301 : Changed activemq-osgi so that it embeds the spring-dm bundles so that we can avoid loading the spring-dm feature which causes Spring version conflicts.

            There is still an issue running the ActiveMQBrokerNdCamelFeatureTest. That test is currently ignored but I re-enabled it against this patch (this test should be enabled but was temporarily disabled because of the Karaf issues)

            The problem is now that spring dm is embedded, it avoids the Karaf issue but the OsgiBundleXmlApplicationContext still has a dependency on Spring and doesn't work properly with Spring 4. Specifically I'm seeing a NoSuchMethodError because it relies on a deprecated method that was removed. Spring DM probably needs to go away entirely for the correct fix.

            java.lang.NoSuchMethodError: org.springframework.core.CollectionFactory.createConcurrentMap(I)Lorg/springframework/core/ConcurrentMap;
                    at org.springframework.osgi.util.internal.ClassUtils.<clinit>(ClassUtils.java:164)
                    at org.springframework.osgi.context.support.TrackingUtil.getService(TrackingUtil.java:160)
                    at org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.lookupNamespaceHandlerResolver(OsgiBundleXmlApplicationContext.java:243)
                    at org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.createNamespaceHandlerResolver(OsgiBundleXmlApplicationContext.java:201)
                    at org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.access$000(OsgiBundleXmlApplicationContext.java:60)
                    at org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext$1.run(OsgiBundleXmlApplicationContext.java:124)
                    at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_60]
                    at org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:119)
                    at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:129)
                    at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:605)
                    at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:509)
                    at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$301(AbstractDelegatedExecutionApplicationContext.java:69)
                    at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$1.run(AbstractDelegatedExecutionApplicationContext.java:186)
                    at org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85)
                    at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.normalRefresh(AbstractDelegatedExecutionApplicationContext.java:182)
                    at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$NoDependenciesWaitRefreshExecutor.refresh(AbstractDelegatedExecutionApplicationContext.java:89)
                    at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175)
                    at org.apache.activemq.osgi.ActiveMQServiceFactory.updated(ActiveMQServiceFactory.java:102)
                    at org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159)[7:org.apache.felix.configadmin:1.8.8]
                    at org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93)[7:org.apache.felix.configadmin:1.8.8]
                    at org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1753)[7:org.apache.felix.configadmin:1.8.8]
                    at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[7:org.apache.felix.configadmin:1.8.8]
                    at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[7:org.apache.felix.configadmin:1.8.8]
                    at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]
            
            cshannon Christopher L. Shannon added a comment - There is still an issue running the ActiveMQBrokerNdCamelFeatureTest. That test is currently ignored but I re-enabled it against this patch (this test should be enabled but was temporarily disabled because of the Karaf issues) The problem is now that spring dm is embedded, it avoids the Karaf issue but the OsgiBundleXmlApplicationContext still has a dependency on Spring and doesn't work properly with Spring 4. Specifically I'm seeing a NoSuchMethodError because it relies on a deprecated method that was removed. Spring DM probably needs to go away entirely for the correct fix. java.lang.NoSuchMethodError: org.springframework.core.CollectionFactory.createConcurrentMap(I)Lorg/springframework/core/ConcurrentMap; at org.springframework.osgi.util.internal.ClassUtils.<clinit>(ClassUtils.java:164) at org.springframework.osgi.context.support.TrackingUtil.getService(TrackingUtil.java:160) at org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.lookupNamespaceHandlerResolver(OsgiBundleXmlApplicationContext.java:243) at org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.createNamespaceHandlerResolver(OsgiBundleXmlApplicationContext.java:201) at org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.access$000(OsgiBundleXmlApplicationContext.java:60) at org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext$1.run(OsgiBundleXmlApplicationContext.java:124) at java.security.AccessController.doPrivileged(Native Method)[:1.8.0_60] at org.springframework.osgi.context.support.OsgiBundleXmlApplicationContext.loadBeanDefinitions(OsgiBundleXmlApplicationContext.java:119) at org.springframework.context.support.AbstractRefreshableApplicationContext.refreshBeanFactory(AbstractRefreshableApplicationContext.java:129) at org.springframework.context.support.AbstractApplicationContext.obtainFreshBeanFactory(AbstractApplicationContext.java:605) at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:509) at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.access$301(AbstractDelegatedExecutionApplicationContext.java:69) at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$1.run(AbstractDelegatedExecutionApplicationContext.java:186) at org.springframework.osgi.util.internal.PrivilegedUtils.executeWithCustomTCCL(PrivilegedUtils.java:85) at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.normalRefresh(AbstractDelegatedExecutionApplicationContext.java:182) at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext$NoDependenciesWaitRefreshExecutor.refresh(AbstractDelegatedExecutionApplicationContext.java:89) at org.springframework.osgi.context.support.AbstractDelegatedExecutionApplicationContext.refresh(AbstractDelegatedExecutionApplicationContext.java:175) at org.apache.activemq.osgi.ActiveMQServiceFactory.updated(ActiveMQServiceFactory.java:102) at org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.updated(ManagedServiceFactoryTracker.java:159)[7:org.apache.felix.configadmin:1.8.8] at org.apache.felix.cm.impl.helper.ManagedServiceFactoryTracker.provideConfiguration(ManagedServiceFactoryTracker.java:93)[7:org.apache.felix.configadmin:1.8.8] at org.apache.felix.cm.impl.ConfigurationManager$UpdateConfiguration.run(ConfigurationManager.java:1753)[7:org.apache.felix.configadmin:1.8.8] at org.apache.felix.cm.impl.UpdateThread.run0(UpdateThread.java:143)[7:org.apache.felix.configadmin:1.8.8] at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:110)[7:org.apache.felix.configadmin:1.8.8] at java.lang.Thread.run(Thread.java:745)[:1.8.0_60]
            gtully Gary Tully added a comment -

            The fix for https://issues.apache.org/jira/browse/AMQ-4727 could maybe be reverted as part of this investigation. It related to allowing the camel context find the bundlecontext and there may well be a better way (or more correct way) to achieve that in 2.17.

            gtully Gary Tully added a comment - The fix for https://issues.apache.org/jira/browse/AMQ-4727 could maybe be reverted as part of this investigation. It related to allowing the camel context find the bundlecontext and there may well be a better way (or more correct way) to achieve that in 2.17.

            Also, if we are able to get this to work with embedding Spring DM, maybe we can do the same with embedding xbean-spring. Xbean requires an older version of Spring as well so we need to either need to ping them for a new release that supports Spring 4.x or try embedding.

            cshannon Christopher L. Shannon added a comment - Also, if we are able to get this to work with embedding Spring DM, maybe we can do the same with embedding xbean-spring. Xbean requires an older version of Spring as well so we need to either need to ping them for a new release that supports Spring 4.x or try embedding.
            soleger Seth Leger added a comment -

            Hi everyone, I just wanted to let you know that my primary motivation is to get ActiveMQ 5.13+ to load in a Karaf container where Spring 4+ is also present. Since the feature version ranges for Spring in the ActiveMQ features restrict Spring to [3.2,4), Spring 3.2 will be installed with ActiveMQ and it will satisfy the Spring dependencies of spring-dm.

            I understand that this is a stopgap measure and that removing the spring-dm dependency would be a better solution (and would be required for full Spring 4.X compatibility). I thought that embedding would be a not-too-invasive way to make ActiveMQ 5.13 compatible with containers where Spring 4 is in use.

            soleger Seth Leger added a comment - Hi everyone, I just wanted to let you know that my primary motivation is to get ActiveMQ 5.13+ to load in a Karaf container where Spring 4+ is also present. Since the feature version ranges for Spring in the ActiveMQ features restrict Spring to [3.2,4), Spring 3.2 will be installed with ActiveMQ and it will satisfy the Spring dependencies of spring-dm. I understand that this is a stopgap measure and that removing the spring-dm dependency would be a better solution (and would be required for full Spring 4.X compatibility). I thought that embedding would be a not-too-invasive way to make ActiveMQ 5.13 compatible with containers where Spring 4 is in use.
            soleger Seth Leger added a comment -

            Embedding spring-dm in activemq-osgi 5.13.X (and merging forward to master) would fix the following version combinations which do not currently load because of the conflicts with the spring-dm feature:

            • Spring 4.X + Camel 2.15 + ActiveMQ 5.13
            • Spring 4.X + Camel 2.16 + ActiveMQ 5.13
            • Spring 4.X + Camel 2.16 + ActiveMQ 5.14-SNAPSHOT

            Another peripheral issue here is that Camel 2.17 has changed their Karaf feature definitions so that the camel-jms feature excludes Spring 4.0 and lower:

            <spring-version-range>[4.1,5)</spring-version-range>
            

            This further restricts the combinations of Spring 4.0, Camel, and ActiveMQ that are compatible within Karaf.

            soleger Seth Leger added a comment - Embedding spring-dm in activemq-osgi 5.13.X (and merging forward to master) would fix the following version combinations which do not currently load because of the conflicts with the spring-dm feature: Spring 4.X + Camel 2.15 + ActiveMQ 5.13 Spring 4.X + Camel 2.16 + ActiveMQ 5.13 Spring 4.X + Camel 2.16 + ActiveMQ 5.14-SNAPSHOT Another peripheral issue here is that Camel 2.17 has changed their Karaf feature definitions so that the camel-jms feature excludes Spring 4.0 and lower: https://github.com/apache/camel/blob/camel-2.17.x/platforms/karaf/features/src/main/resources/features.xml https://github.com/apache/camel/blob/camel-2.17.x/parent/pom.xml <spring-version-range> [4.1,5) </spring-version-range> This further restricts the combinations of Spring 4.0, Camel, and ActiveMQ that are compatible within Karaf.
            soleger Seth Leger added a comment -

            Can we target this issue for ActiveMQ 5.14? I would hate to see it get released and have OSGi compatibility with Spring 4.X still remain broken.

            soleger Seth Leger added a comment - Can we target this issue for ActiveMQ 5.14? I would hate to see it get released and have OSGi compatibility with Spring 4.X still remain broken.

            Something will need to be done for 5.14 to fix OSGi, either a solution such as this or even removing spring-dm entirely in time for 5.14. I would prefer to remove spring-dm entirely (which is why I haven't merged this in yet) but there might be some issues with that which would make this another option to go with.

            cshannon Christopher L. Shannon added a comment - Something will need to be done for 5.14 to fix OSGi, either a solution such as this or even removing spring-dm entirely in time for 5.14. I would prefer to remove spring-dm entirely (which is why I haven't merged this in yet) but there might be some issues with that which would make this another option to go with.
            cshannon Christopher L. Shannon added a comment - - edited

            I did some more digging into this today to see what we would need to do to drop spring-dm for our 5.14 release. I think we need a couple of new versions. First, xbean-spring needs a new release that supports spring 4.x. There is an open ticket here: https://issues.apache.org/jira/browse/XBEAN-287

            Second, looks like Camel 2.18 is going to drop the spring-dm dependency from spring-camel. So I think we will need to wait for that version of Camel to be released to drop spring-dm because camel-spring 2.17 has a dependency on Spring 3.x for spring-dm support. In version 2.18 spring-dm support has been separated out so camel-spring will work with spring 4.x.

            cshannon Christopher L. Shannon added a comment - - edited I did some more digging into this today to see what we would need to do to drop spring-dm for our 5.14 release. I think we need a couple of new versions. First, xbean-spring needs a new release that supports spring 4.x. There is an open ticket here: https://issues.apache.org/jira/browse/XBEAN-287 Second, looks like Camel 2.18 is going to drop the spring-dm dependency from spring-camel. So I think we will need to wait for that version of Camel to be released to drop spring-dm because camel-spring 2.17 has a dependency on Spring 3.x for spring-dm support. In version 2.18 spring-dm support has been separated out so camel-spring will work with spring 4.x.
            soleger Seth Leger added a comment -

            Hi Christopher, I just wanted to provide feedback that in our environment (Camel and ActiveMQ with only Blueprint inside Karaf) I don't think we have any dependency on camel-spring. If ActiveMQ removes its spring-dm dependency now, our environment would be free of spring-dm even though we also use Camel.

            soleger Seth Leger added a comment - Hi Christopher, I just wanted to provide feedback that in our environment (Camel and ActiveMQ with only Blueprint inside Karaf) I don't think we have any dependency on camel-spring. If ActiveMQ removes its spring-dm dependency now, our environment would be free of spring-dm even though we also use Camel.

            Right, I think just Camel 2.17 requires camel-spring.

            For 5.14.0, I think the correct thing is to drop spring-dm and maybe just support Camel 2.18+ for OSGi environments. It sounds like Camel 2.18 is on track for a August/September release.

            As far as 5.13.x, embedding Spring dm may end up being the way to go to get Camel 2.16 to work properly (or even backing out that patch as Gary pointed out)

            cshannon Christopher L. Shannon added a comment - Right, I think just Camel 2.17 requires camel-spring. For 5.14.0, I think the correct thing is to drop spring-dm and maybe just support Camel 2.18+ for OSGi environments. It sounds like Camel 2.18 is on track for a August/September release. As far as 5.13.x, embedding Spring dm may end up being the way to go to get Camel 2.16 to work properly (or even backing out that patch as Gary pointed out)
            soleger Seth Leger added a comment -

            Thanks for clarifying, I wasn't aware that Camel 2.17 required camel-spring. I totally agree with everything here. I wish it was easier but it's tough to line up dependencies sometimes.

            soleger Seth Leger added a comment - Thanks for clarifying, I wasn't aware that Camel 2.17 required camel-spring. I totally agree with everything here. I wish it was easier but it's tough to line up dependencies sometimes.

            Commit 927bef7345dfff779209d3c3291d0df51f41583d in activemq's branch refs/heads/master from soleger
            [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=927bef7 ]

            AMQ-6301: Changed activemq-osgi so that it embeds the spring-dm bundles
            so that we can avoid loading the spring-dm feature which causes Spring
            version conflicts.

            jira-bot ASF subversion and git services added a comment - Commit 927bef7345dfff779209d3c3291d0df51f41583d in activemq's branch refs/heads/master from soleger [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=927bef7 ] AMQ-6301 : Changed activemq-osgi so that it embeds the spring-dm bundles so that we can avoid loading the spring-dm feature which causes Spring version conflicts.

            Commit a2205f69193ccde4441f5bad3826fc77921e4177 in activemq's branch refs/heads/master from cshannon
            [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=a2205f6 ]

            https://issues.apache.org/jira/browse/AMQ-6301

            This closes #187

            jira-bot ASF subversion and git services added a comment - Commit a2205f69193ccde4441f5bad3826fc77921e4177 in activemq's branch refs/heads/master from cshannon [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=a2205f6 ] https://issues.apache.org/jira/browse/AMQ-6301 This closes #187

            Commit 6c2ce67ffbde081f1db75002c8b41c3c7b7bb166 in activemq's branch refs/heads/master from cshannon
            [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=6c2ce67 ]

            https://issues.apache.org/jira/browse/AMQ-6301

            Updating ActiveMQServiceFactory to avoid using Spring DM directly and
            instead use the Camel factory bean if it exists

            Reverting back to Camel 2.16.3 until Spring DM is removed and Spring 4
            can be used

            jira-bot ASF subversion and git services added a comment - Commit 6c2ce67ffbde081f1db75002c8b41c3c7b7bb166 in activemq's branch refs/heads/master from cshannon [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=6c2ce67 ] https://issues.apache.org/jira/browse/AMQ-6301 Updating ActiveMQServiceFactory to avoid using Spring DM directly and instead use the Camel factory bean if it exists Reverting back to Camel 2.16.3 until Spring DM is removed and Spring 4 can be used

            Commit 982f739e24fce445dc58a1814ba30d479442ea29 in activemq's branch refs/heads/activemq-5.13.x from soleger
            [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=982f739 ]

            AMQ-6301: Changed activemq-osgi so that it embeds the spring-dm bundles
            so that we can avoid loading the spring-dm feature which causes Spring
            version conflicts.

            jira-bot ASF subversion and git services added a comment - Commit 982f739e24fce445dc58a1814ba30d479442ea29 in activemq's branch refs/heads/activemq-5.13.x from soleger [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=982f739 ] AMQ-6301 : Changed activemq-osgi so that it embeds the spring-dm bundles so that we can avoid loading the spring-dm feature which causes Spring version conflicts.

            Commit 9da728407bb07ed9ad35ea12c3d8180382b0cc51 in activemq's branch refs/heads/activemq-5.13.x from cshannon
            [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=9da7284 ]

            https://issues.apache.org/jira/browse/AMQ-6301

            Updating ActiveMQServiceFactory to avoid using Spring DM directly and
            instead use the Camel factory bean if it exists

            Reverting back to Camel 2.16.3 until Spring DM is removed and Spring 4
            can be used

            jira-bot ASF subversion and git services added a comment - Commit 9da728407bb07ed9ad35ea12c3d8180382b0cc51 in activemq's branch refs/heads/activemq-5.13.x from cshannon [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=9da7284 ] https://issues.apache.org/jira/browse/AMQ-6301 Updating ActiveMQServiceFactory to avoid using Spring DM directly and instead use the Camel factory bean if it exists Reverting back to Camel 2.16.3 until Spring DM is removed and Spring 4 can be used

            I merged the PR to embed spring DM. I also changed the factory class and completely removed the spring DM OSGi usage and bootstrapped camel in a different way to prevent problems and for preparation for a future release.

            I also reverted back to camel 2.16.3 in master for now until we can upgrade to Camel 2.18 and remove Spring DM completely.

            cshannon Christopher L. Shannon added a comment - I merged the PR to embed spring DM. I also changed the factory class and completely removed the spring DM OSGi usage and bootstrapped camel in a different way to prevent problems and for preparation for a future release. I also reverted back to camel 2.16.3 in master for now until we can upgrade to Camel 2.18 and remove Spring DM completely.
            githubbot ASF GitHub Bot added a comment -

            Github user asfgit closed the pull request at:

            https://github.com/apache/activemq/pull/187

            githubbot ASF GitHub Bot added a comment - Github user asfgit closed the pull request at: https://github.com/apache/activemq/pull/187
            gtully Gary Tully added a comment -

            cshannon there is a related unit test that may benefit from the new bootstrap - it has been disabled for a while but is a valid use case
            https://github.com/apache/activemq/blob/28e4090d9561a1cd2a630bc35257539c30a13cf1/activemq-karaf-itest/src/test/java/org/apache/activemq/karaf/itest/ActiveMQBrokerNdExternalCamelFeatureTest.java#L48

            maybe that will work ok with this fix or maybe the root cause of the failure will be more apparent.
            A sort of, while you are in those weeks suggestion

            gtully Gary Tully added a comment - cshannon there is a related unit test that may benefit from the new bootstrap - it has been disabled for a while but is a valid use case https://github.com/apache/activemq/blob/28e4090d9561a1cd2a630bc35257539c30a13cf1/activemq-karaf-itest/src/test/java/org/apache/activemq/karaf/itest/ActiveMQBrokerNdExternalCamelFeatureTest.java#L48 maybe that will work ok with this fix or maybe the root cause of the failure will be more apparent. A sort of, while you are in those weeks suggestion

            Commit 159713298aec60e49f5f3dae7f548a4162af9598 in activemq's branch refs/heads/master from cshannon
            [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=1597132 ]

            https://issues.apache.org/jira/browse/AMQ-6301

            using the proper command name in karaf after upgrading from karaf 2 to
            4

            jira-bot ASF subversion and git services added a comment - Commit 159713298aec60e49f5f3dae7f548a4162af9598 in activemq's branch refs/heads/master from cshannon [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=1597132 ] https://issues.apache.org/jira/browse/AMQ-6301 using the proper command name in karaf after upgrading from karaf 2 to 4

            Commit 70e2b92f1b7410f6b511ed8d0d2d1878e56f5331 in activemq's branch refs/heads/activemq-5.13.x from cshannon
            [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=70e2b92 ]

            https://issues.apache.org/jira/browse/AMQ-6301

            using the proper command name in karaf after upgrading from karaf 2 to
            4

            (cherry picked from commit 159713298aec60e49f5f3dae7f548a4162af9598)

            jira-bot ASF subversion and git services added a comment - Commit 70e2b92f1b7410f6b511ed8d0d2d1878e56f5331 in activemq's branch refs/heads/activemq-5.13.x from cshannon [ https://git-wip-us.apache.org/repos/asf?p=activemq.git;h=70e2b92 ] https://issues.apache.org/jira/browse/AMQ-6301 using the proper command name in karaf after upgrading from karaf 2 to 4 (cherry picked from commit 159713298aec60e49f5f3dae7f548a4162af9598)

            I looked at the test a bit and it is still broken. The good news is that when running it the camel changes are picked up when deployed. The problem is that the bundle is refreshed after camel is dynamically added and this is causing the test to have a ClassNotFoundException that says the bundle wiring is no longer valid because PaxExam is now running inside of a bundle that has been refreshed, etc. This is most likely just a test issue and not going to be a problem with a real instance.

            cshannon Christopher L. Shannon added a comment - I looked at the test a bit and it is still broken. The good news is that when running it the camel changes are picked up when deployed. The problem is that the bundle is refreshed after camel is dynamically added and this is causing the test to have a ClassNotFoundException that says the bundle wiring is no longer valid because PaxExam is now running inside of a bundle that has been refreshed, etc. This is most likely just a test issue and not going to be a problem with a real instance.

            People

              cshannon Christopher L. Shannon
              soleger Seth Leger
              Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: