activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael André Pearce <michael.andre.pea...@me.com>
Subject Re: [DISCUSS] Custom Object Serialisation Support
Date Wed, 31 May 2017 20:58:49 GMT
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 <michael.andre.pearce@me.com> 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 <clebert.suconic@gmail.com> 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
>> <michael.andre.pearce@me.com> 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 <mattrpav@gmail.com> 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 <michael.andre.pearce@me.com>
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 <mattrpav@gmail.com>
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 <michael.andre.pearce@me.com>
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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message