I don’t think an equivalent for the “activemq-broker” Camel component is needed - just my opinion there.
As far as a “artemis-camel” or “camel-artemis” component goes, I don’t think one is “needed” - but I’m wondering if a specific component could provide any value over using just the JMS abstractions. If everything you can do in “core” is available (or will be available) via the JMS abstractions, then I don’t see a compelling reason for a component dedicated to Artemis - unless of course configuring the component becomes too complex or the JMS abstractions incur too much overhead. If it is decided that a specific component would provide some value, I would like to see it in the Camel project and not in Artemis (i.e. camel-artemis instead of artemis-camel). Just my opinion ... > On Oct 24, 2016, at 4:40 PM, Clebert Suconic <clebert.suco...@gmail.com> > wrote: > > - There is an “activemq-camel” component today, and since Artemis is > slated to become the next “ActiveMQ”, I was looking for functional > equivalents. This is actually what started the whole question for me, > because I can do everything I need to do in core Artemis without > muddying the waters with JMS abtractions. For example, the aliases > that get created for JMS destinations really confused me at first. > > > We are fixing the destinations on next release (1.6.0) 1.5.0 is bound > to be released this week. > > > > Do we need a camel component within Artemis? if we do we can create > one.. but every I ask this question I get the same answer that we > don't need it given it's a bit different with Artemis. > > > if you found a real need we can certainly create it. > > > On Mon, Oct 24, 2016 at 1:32 PM, Quinn Stevenson > <qu...@pronoia-solutions.com> wrote: >> I can stick with JMS - I’ve used JMS servers for a long time, and I can get >> what I need done that way. >> >> There are a couple of reasons behind the question: >> >> - I try to keep my dependencies to a minimum. When I use JMS in camel >> currently, I use camel-sjms whenever I can (basically whenever I don’t need >> XA) because the configuration is simpler and I don’t drag in all the Spring >> dependencies. The camel-sjms component does some other things better IMO >> opinion as well - but it’s mostly because it’s simpler to configure and >> easier to use IMO. >> >> - There is an “activemq-camel” component today, and since Artemis is slated >> to become the next “ActiveMQ”, I was looking for functional equivalents. >> This is actually what started the whole question for me, because I can do >> everything I need to do in core Artemis without muddying the waters with JMS >> abtractions. For example, the aliases that get created for JMS destinations >> really confused me at first. >> >> As an aside, there isn’t an equivalent for the activemq-broker component. I >> don’t really use that one, but it can be handy. I guess I could do this >> with a diverter, but I haven’t tried yet. >> >> >>> On Oct 20, 2016, at 12:38 PM, Clebert Suconic <clebert.suco...@gmail.com> >>> wrote: >>> >>> the JMS layer on Artemis is a thin layer on top of the Core API. I >>> would stick to JMS or JMS2. >>> >>> There are some extra controls you can have on addresses and queues but >>> that will soon also come into JMS after martyn is done with the >>> refactoring on addressing here: >>> >>> https://github.com/apache/activemq-artemis/tree/ARTEMIS-780 >>> >>> On Wed, Oct 19, 2016 at 8:50 AM, Tim Bain <tb...@alumni.duke.edu> wrote: >>>> What's the reason behind wanting to avoid using the JMS layer in favor of >>>> the proprietary Artemis core API? I've not done anything with Artemis, so >>>> this is very much a question from a place of ignorance, but Quinn's >>>> statement sounded a lot like "I only want to use Hibernate-proprietary >>>> APIs, none of those pesky JPA-standard ones that might let me interoperate >>>> or swap underlying technologies later," and I'm curious about the logic >>>> that led to the statement... >>>> >>>> Tim >>>> >>>> On Oct 18, 2016 3:55 PM, "Clebert Suconic" <clebert.suco...@gmail.com> >>>> wrote: >>>> >>>>> On Tue, Oct 18, 2016 at 12:45 PM, Quinn Stevenson >>>>> <qu...@pronoia-solutions.com> wrote: >>>>>> Clebert - >>>>>> >>>>>> Thank you for your input! >>>>>> >>>>>> I try and avoid XA transactions whenever possible as well. I do have a >>>>> few customers that insist on transactions when they do JMS->JMS routes >>>>> (the >>>>> JMS destination are in different brokers/servers - hence the need for XA). >>>>> >>>>> got it... was just pointing my 2 cents there. Try to batch (like 1000 >>>>> messages & 1000 whatever else you are doing on a single TX). if you >>>>> can. >>>>> >>>>>> >>>>>> This is really the last piece I need to figure out before I’ll be able >>>>> to implement Artemis (core only) into our standard flows. I know we can >>>>> always use the JMS layer, but I’d like to be able to use just the core if >>>>> I >>>>> can. >>>>>> >>>>> >>>>> all the methods available on JMS for XA are also available on >>>>> ClientSession. There shouldn't be any difference. >>>>> >>>>> Let me know If you can't figure out, and I (or someone else) may write >>>>> an example >>>>> >>>>> >>>>>> I’m planning on doing the integration in Camel, and it’s looking more >>>>> and more like I’ll need an “artemis-camel” (hosted in the Artemis source) >>>>> or a “camel-artemis” (hosted in the Camel Components source). Any >>>>> thoughts >>>>> on which would be the most appropriate place for the component? ActiveMQ >>>>> 5.x has the activemq-camel component, but it always seemed to me it was in >>>>> the wrong place - that it should be camel-activemq. >>>>>> >>>>> >>>>> >>>>> I looked at the camel component on AMQ5 at some time ago and it would >>>>> be simple to port it. I thought it wasn't needed though. but if you >>>>> need it we can add something into artemis/master just like AMQ5 has >>>>> one. >>>>> >>>>> Can you add it? Send a PR... we accept PRs :) >>>>> >>>>> >>>>> if you even send it soon, I'm planning a release early next week. if >>>>> it's well done (well done means.. not breaking anything) it might be >>>>> there before we release it. >>>>> >>> >>> >>> >>> -- >>> Clebert Suconic >> > > > > -- > Clebert Suconic
