To help discussion, A very very basic implementation just to simulate the idea. https://github.com/michaelandrepearce/activemq-artemis/tree/CustomSerialisation <https://github.com/michaelandrepearce/activemq-artemis/tree/CustomSerialisation>
n.b. doesn’t fully compile is just pseudo impl, nor doesn’t include bits as discussed below like map/change type to a byte message for compatibility, nor media type idea. Cheers Mike > On 31 May 2017, at 21:19, Michael André Pearce <[email protected]> > wrote: > > @matt > > Very much so, case in point would be the Avro use case. It plays very nicely > to interop object/data serialisation with c++ clients. Or like wise some of > the other serialisation options out there. > > This is why I suggest a not Java specific but more generic/widely adopted > content-type media type header. > > Sent from my iPhone > >> On 31 May 2017, at 20:02, Clebert Suconic <[email protected]> wrote: >> >> I'm a bit confused about what API are you talking about... >> >> do you intend for having that as an extension of the JMS Client.. >> (including qpid).. or as a tooling in which you could convert bytes >> and buffers to the intended format. >> >> On Wed, May 31, 2017 at 2:44 PM, Michael André Pearce >> <[email protected]> wrote: >>> Hi Matt, >>> >>> I would suggest that serdes have to provide a mime type, we will have to >>> add method to expose this, and then we set content-type to the provided >>> mime type string. >>> >>> Maybe simple method: >>> >>> String mimeType() >>> >>> As such if on byte message on consume if custom serdes exist and content >>> type header exists and matches that returned from the serdes we deserialise >>> via custom. >>> >>> >>> >>> >>> Sent from my iPhone >>> >>>> On 31 May 2017, at 17:58, Matt Pavlovich <[email protected]> wrote: >>>> >>>> Hey Mike- >>>> >>>> You bring up some good points about keeping the serialization simple and >>>> separate. I’m good w/ that approach. >>>> >>>> The API you propose doesn’t seem to indicate a place to touch the message >>>> headers. Are you suggesting that the Artemis client-side SerDes handler >>>> would have a convention where it would set the classname or other in a >>>> standard header? BTW— I think that defining a standard convention would be >>>> preferred. users could still have access to headers / properties ahead of >>>> calling the .send(..). >>>> >>>> -Thanks, >>>> Matt >>>> >>>>> On May 30, 2017, at 9:00 PM, Michael André Pearce >>>>> <[email protected]> wrote: >>>>> >>>>> Hi Matt, >>>>> >>>>> I think having just a SerDe interface for payload handling separate from >>>>> a general interceptor / client side plugin, is beneficial as then it >>>>> keeps the logic for serialsation well encapsulated. And also cleaner if >>>>> we need to do anything (eg sending it as a bytesmessags with a header >>>>> flag) >>>>> >>>>> I see this very much like difference in kafka where you have payload >>>>> serialisation (serdes) and custom-plugin (interceptors) >>>>> >>>>> Also having just a serde makes interface for people to implement and care >>>>> about much simpler. Eg this is almost the interface I would expect: >>>>> >>>>> byte[] serialize(Destination destination, Object o) >>>>> >>>>> Object deserialize(Destination destination, byte[] bytes) >>>>> >>>>> Nice and simple to implement without having to care about anything else. >>>>> >>>>> Cheers >>>>> Mike >>>>> >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On 30 May 2017, at 23:18, Matt Pavlovich <[email protected]> wrote: >>>>>> >>>>>> Michael- >>>>>> >>>>>> +1 dealing with bytes messages is preferred to object messages and >>>>>> custom object SerDes is super useful. >>>>>> >>>>>> What do you think about considering a generic client-side plugin >>>>>> approach vs just a payload handler? >>>>>> >>>>>>> On May 30, 2017, at 4:03 PM, Michael André Pearce >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> If present then this would be used to serialise the Object instead of >>>>>>> the default, and subsequently create/convert to a BytesMessage, with a >>>>>>> header set to denote it was custom serialised. >>>>>> >>>> >> >> >> >> -- >> Clebert Suconic
