I would say just use camel-jms (http://camel.apache.org/jms.html <http://camel.apache.org/jms.html>) or camel-sjms (http://camel.apache.org/sjms.html <http://camel.apache.org/sjms.html>).
> On Oct 25, 2016, at 2:56 PM, Clebert Suconic <clebert.suco...@gmail.com> > wrote: > > I guess I should add that to the FAQ. I get this question once in a while. > > How would we describe it? there's no need for an Artemiq-Camel > component at the moment, just use what? > > > Any camel specialist can provide me a simple answer to add to the doc? > > On Tue, Oct 25, 2016 at 12:22 PM, Quinn Stevenson > <qu...@pronoia-solutions.com> wrote: >> 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 >> > > > > -- > Clebert Suconic
