Yeas but we just want a JMS Api wrapper that exposes again JMS api, here. Sent from my iPhone
> On 2 Jun 2017, at 18:04, Timothy Bish <[email protected]> wrote: > >> On 06/02/2017 11:08 AM, Clebert Suconic wrote: >> You know what would be cool IMO? >> >> Create a camel-jms-tool / camel-jms-wrapper (whatever the name you need): > > Camel already has a JMS wrapper that takes a connection factory, it's called > camel-jms, or if you don't want any spring deps then camel-sjms > >> Add a couple of tools there: >> - The connection factory that we need to share with qpid-jms >> - This class that Micahel is writing.. >> >> >> and it would be a nice marriage. This camel-jms-wrapper could be >> lightweight and offer not many dependencies on camel itself. >> >> >> Just brain storming ^^^^ >> >> On Fri, Jun 2, 2017 at 10:16 AM, Clebert Suconic >> <[email protected]> wrote: >>> On Fri, Jun 2, 2017 at 5:26 AM, Martyn Taylor <[email protected]> wrote: >>>> So, I could originally see a requirement for controlling the >>>> (de)serialization process for performance or security reasons, whilst also >>>> controlling data format. I still think having something light weight that >>>> gives users control over this (outside of overriding the java serialization >>>> methods) may be useful. It would only take a couple of lines of code in >>>> the client to do it. >>> >>> I think so... Camel will .. as far as I know.. will make you commit >>> the consumer and do an ack on every message received like MDBs do... >>> >>> Introducing Camel just for the sake of serialization doesn't seem the >>> right decision to me.. there's a lot more interesting on Camel than >>> just the serialization mechanism. >>> >>> >>> >>>> But, if this thread is really only about integrating multiple technologies, >>>> by controlling bytes that are sent over the wire then I have to agree with >>>> Tim, in that Camel does seem to be a good fit for this problem. Michael, I >>>> can see your point re: the success of the Kafka model, if you feel that >>>> this is largely down to the API and the abstraction of the serialization >>>> process, how about just wrapping a Camel context? >>> >>> I am not sure what performance implications this would make.. and it >>> seems more complicated to be used. >>> >>> A simpler API has a higher chance of success. >> >> > > -- > Tim Bish > twitter: @tabish121 > blog: http://timbish.blogspot.com/ >
