So our one in our org is avro. This is about enabling users to choose their own. Java serialisation is one of the worst for comparibility but annoyingly the default. And one of the worst perfomance wise. This is why its so good to provide this customisation, as users anyhow many time do their own, be it json, avro, thrift of the object. Just clunky currently. Look at the success here of Kakfa with this flexibilty. Thus why ability to set a custom serialiser at factory level would be so useful.
Sent from my Samsung Galaxy smartphone. -------- Original message --------From: Arthur Naseef <a...@amlinv.com> Date: 25/05/2018 22:34 (GMT+00:00) To: dev@activemq.apache.org Subject: Re: Custom serialization mechanism for ActiveMQMessages Just a thought that I hope helps... Please be careful about serialization and deserialization of objects. Lots of security issues arise when using object serialization/deserialization in practice. Also, compatibility issues creep up. Sending a text format over the wire, such as JSON, is typically the best way to go all around. There are lots of packages which provide easy conversion between JSON and model objects (in many programming languages). Art On Fri, May 25, 2018 at 1:36 PM, michael.andre.pearce < michael.andre.pea...@me.com> wrote: > Typo but important one. > I think = i dont think > > > Sent from my Samsung Galaxy smartphone. > -------- Original message --------From: "michael.andre.pearce" < > michael.andre.pea...@me.com> Date: 25/05/2018 21:35 (GMT+00:00) To: > dev@activemq.apache.org Subject: Re: Custom serialization mechanism for > ActiveMQMessages > @Clebert > I think jms spec defines or cares how it should serialize especially over > the wire, this is left to implementation, just that class should be > serializable. > This is just implementation detail, keeping to the api method spec, so > doesnt need a new jms type. > > > Sent from my Samsung Galaxy smartphone. >
