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.
