This would be good if the camel team are on board. If not as a fail back would we be happy having some common JMS api tools as an extensions/tooling package?
Sent from my iPhone > On 2 Jun 2017, at 16:08, Clebert Suconic <[email protected]> wrote: > > You know what would be cool IMO? > > Create a camel-jms-tool / camel-jms-wrapper (whatever the name you need): > > 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. > > > > -- > Clebert Suconic
