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. >>
