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
