Hi I think the fix for AMQ-6576 embeds already the spring xbean in activemq-osgi.
Kindly regards Krzysztof On 08.02.2017 13:53, Christopher Shannon wrote: > Since the plan would be to deprecate the plugin first (like we did with > leveldb) then I guess that means it would still stick around for 5.15.0 so > we still need an upgrade path for Camel 2.18.x and we need to fix the OSGi > integration. I think the first step will be to embed the xbean library > (maybe the activemq-spring project) and look for a better approach in the > future. > > On Wed, Feb 8, 2017 at 5:07 AM, Claus Ibsen <[email protected]> wrote: > >> On Wed, Feb 8, 2017 at 9:59 AM, Claus Ibsen <[email protected]> wrote: >>> On Tue, Feb 7, 2017 at 11:38 AM, Christian Schneider >>> <[email protected]> wrote: >>>> There are some issues supporting the new camel version 2.18.x in >> activemq. >>>> See >>>> >>>> https://issues.apache.org/jira/browse/AMQ-6585 >>>> >>> I think this ticket surfaces a problem in ActiveMQ about its OSGi >>> code/stuff being problematic. That its xbean stuff is causing more >>> pain than good. I wonder if ActiveMQ should consider a different >>> approach for those xml file configurations to work without xbean or >>> make it work for OSGi. >>> >>> >>> Moving activemq-camel to Apache Camel moves the dependency problem to >>> Camel. However as Camel uses ActiveMQ for testing camel-jms we already >>> use AMQ, so it may be less of a problem there. >>> >>> Also it allows activme-camel to be released together with Camel and >>> benefit from new functionality from Camel being released together. >>> >>> And we could potentially make activemq-camel (to be renamed to >>> camel-activemq) just reuse all the unit tests from camel-jms so we >>> dont have to write any tests and just let it be an optimized camel-jms >>> component which it really is. >>> >>> >>> >>>> In the issue we discussed that it would be better to have the activemq >> camel >>>> component in the camel project. There is also the question about the >> camel >>>> plugin for the broker. I do not know any users who use camel inside the >>>> activemq broker. So the proposal here is to deprecate and remove the >> plugin >>>> at some point. >>>> >>> There are some community users that uses the Camel broker component. >>> I dont yet think it should be deprecated. It allows functionality that >>> there is not in ActiveMQ. >>> And ActiveMQ ships with Camel and Camel and AMQ together is a great >> combination. >>> >>>> If both are removed from activemq source then managing the dependencies >> is a >>>> lot easier. >>>> >>> I frankly think its the OSGi pain that is causing this. If AMQ just >>> works on OSGi then this wouldn't be a problem in the first place. >>> >>> -0 to broker (need more feedback from community and others) >> For the broker component you can likely just use a Camel XML file and >> use Camel routes to do the same as the broker component can do. >> >> And there hasn't been too many users of it so far, but a few have been >> doing so. And if they can migrate to using plain Camel routes then it >> makes sense to deprecate it too. >> >> So let me change to +1 >> >> >>> +1 to activemq-camel (however need to see how bad/good this is and >>> allow to revert the decision if it causes to much pain) >>> >>> >>>> What do you think? >>>> >>>> Christian >>>> >>>> >>>> -- >>>> Christian Schneider >>>> http://www.liquid-reality.de >>>> >>>> Open Source Architect >>>> http://www.talend.com >>>> >>> >>> >>> -- >>> Claus Ibsen >>> ----------------- >>> http://davsclaus.com @davsclaus >>> Camel in Action 2: https://www.manning.com/ibsen2 >> >> >> -- >> Claus Ibsen >> ----------------- >> http://davsclaus.com @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2 >> -- Krzysztof Sobkowiak (@ksobkowiak) JEE & OSS Architect, Integration Architect Apache Software Foundation Member (http://apache.org/) Apache ServiceMix Committer & PMC Member (http://servicemix.apache.org/) Senior Solution Architect @ Capgemini SSC (http://www.capgeminisoftware.pl/)
