Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
MIME-Version: 1.0
In-Reply-To: <2c47d851-da37-1277-2699-0451df93fbe6@gmail.com>
References: <95C56966-F848-47A0-B587-9F0E9AAE06F9@me.com> <1D42C4DB-B265-40FA-8C50-80423BC81289@gmail.com>
 <984A9C1D-72E2-4B62-965C-374C407A45EB@me.com> <F51605BC-47A0-45F4-AE79-91C021E293A7@gmail.com>
 <81F7E4E3-3C95-41C4-A81C-A984F5A004D5@me.com> <CAKF+bsraE6oYPfsrN5zjM7ySR5Uwq1c6gnvk6sjOp6hbpuX3pg@mail.gmail.com>
 <943F83FE-20A4-42C7-B218-9307986DB43B@me.com> <60F6BF2D-DF79-4C73-BB8B-B3396FA092FC@me.com>
 <592F37A1.9020500@gmail.com> <9FA3393F-16B3-4E1F-A692-749B42F180B6@me.com>
 <CAKF+bsppAHNA6Pv4cYA0wnUdzhDTOvYSH40SUyYCx=Jq4eWtWA@mail.gmail.com>
 <DB94ACE2-3887-4821-9759-8AABEDC21AD0@me.com> <D3C2E898-B3C5-4D32-9654-5DBDC8F62CBD@me.com>
 <CAH6wpnoHbEJuTzoTkEecmvq4iLrsGYoW8QN+tm_YPjLPYRFx+A@mail.gmail.com> <2c47d851-da37-1277-2699-0451df93fbe6@gmail.com>
From: Martyn Taylor <mtaylor@redhat.com>
Date: Thu, 1 Jun 2017 14:34:47 +0100
Message-ID: <CAH6wpnq752tPzX+FaHwDpwySVszvmKcG9UhMPcq9vr7oSdyy6Q@mail.gmail.com>
Subject: Re: [DISCUSS] Custom Object Serialisation Support
To: dev@activemq.apache.org
Content-Type: multipart/alternative; boundary="001a11436faebcfb920550e61922"
archived-at: Thu, 01 Jun 2017 13:34:56 -0000

--001a11436faebcfb920550e61922
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish <tabish121@gmail.com> wrote:

> On 06/01/2017 08:51 AM, Martyn Taylor wrote:
>
>> I get the use case for using JSON/XML, particularly for cross language
>> communication.
>>
>> One way users get around this problem right now is just to serialize
>> to/from XML/JSON at the client application level and just use JMS
>> TextMessages to send the data. I guess the idea here to remove that
>> complexity from the client application and into the client via these
>> pluggable serializer objects?  Removing the serizliation logic out of co=
de
>> and into configuration.
>>
>> Providing I've understood this properly, it seems like a good idea to me=
.
>>   so +1.
>>
>
> This problem has already been solved via frameworks like Apache Camel,
> putting such complexity into the JMS client is solving a problem that's
> already been solved and in much more flexible and configurable ways.


Thanks Tim.  I am not a Camel expert in any shape or form, how much
additional complexity/configuration would be required to do something
similar with Camel?  My understanding of the proposal here is really just
to give control back to the user in terms of how their objects are
serialized.  I'd expect this to be pretty light weight, just allow a user
to configure a class to do the serialization.


>
>> On Thu, Jun 1, 2017 at 7:44 AM, Michael Andr=C3=A9 Pearce <
>> michael.andre.pearce@me.com> wrote:
>>
>> I think i might be getting the problem, use case you want to go for, whi=
ch
>>> is to possible serialise to JSON or XML, because they're supported well
>>> in
>>> other languages like c++, which won't read a java serialised object, an=
d
>>> say for XML you generate objects via an XSD which by default aren't
>>> serialisable, so you cannot simply add Serializable to the object, as i=
ts
>>> generated at build.
>>>
>>> Is this the problem we need to solve? If so:
>>>
>>> To get around this normally the tools that generate objects for
>>> serialisation from schema such as XSD do support a way to toggle or
>>> change
>>> the generation slightly for some common use cases.
>>>
>>> In case of XSD, where using jaxb it would be to add something like the
>>> below to jaxb global bindings:
>>>
>>> <xs:annotation>
>>> <xs:appinfo>
>>> <jaxb:globalBindings generateIsSetMethod=3D"true">
>>> <xjc:serializable uid=3D"12343"/>
>>> </jaxb:globalBindings>
>>> </xs:appinfo>
>>> </xs:annotation>
>>>
>>> like wise if you are generating POJO's from a jsonschema using for say
>>> the
>>> tool jsonschema2pojo  there is a toggle in the maven plugin serializabl=
e
>>> which you can switch to true.
>>>
>>> Obviously if you hand crank your DTO Pojo's then it's a case of simply
>>> add
>>> implement  Serializable to the class.
>>>
>>> Cheers
>>> Mike
>>>
>>> Sent from my iPhone
>>>
>>> On 1 Jun 2017, at 06:57, Michael Andr=C3=A9 Pearce <
>>>>
>>> michael.andre.pearce@me.com> wrote:
>>>
>>>> we could but then it wouldn't work via jms api. Typically if using jms
>>>>
>>> the only custom or specific broker object is the connection factory the
>>> rest you code to Jms.
>>>
>>>>
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On 1 Jun 2017, at 04:10, Clebert Suconic <clebert.suconic@gmail.com>
>>>>>
>>>> wrote:
>>>
>>>> On Wed, May 31, 2017 at 10:47 PM Michael Andr=C3=A9 Pearce <
>>>>> michael.andre.pearce@me.com> wrote:
>>>>>
>>>>> Jms api dictates class set in object message to be serializable.
>>>>>>
>>>>>
>>>>> We could make an extension. It could be an extra message this actuall=
y.
>>>>>
>>>>>
>>>>>>
>>>>>> On 31 May 2017, at 22:37, Timothy Nodine <timgnodine@gmail.com>
>>>>>>>
>>>>>> wrote:
>>>
>>>> Should the interface require the underlying class to be Serializable?
>>>>>>>
>>>>>> One use case might be to provide serialization to classes that aren'=
t
>>>>>> natively serializable.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Michael Andr=C3=A9 Pearce wrote:
>>>>>>>
>>>>>>>> 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=E2=80=99t fully compile is just pseudo impl, nor doesn=E2=
=80=99t include
>>>>>>>>
>>>>>>> bits as discussed below like map/change type to a byte message for
>>>>>> compatibility, nor media type idea.
>>>>>>
>>>>>>> Cheers
>>>>>>>> Mike
>>>>>>>>
>>>>>>>> --
>>>>> Clebert Suconic
>>>>>
>>>>
>
> --
> Tim Bish
> twitter: @tabish121
> blog: http://timbish.blogspot.com/
>
>

--001a11436faebcfb920550e61922--