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
