On Thu, Jun 1, 2017 at 2:45 PM, Timothy Bish <[email protected]> wrote:
> On 06/01/2017 09:34 AM, Martyn Taylor wrote: > >> On Thu, Jun 1, 2017 at 2:32 PM, Timothy Bish <[email protected]> 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 >>>> code >>>> 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. >> > > Camel offers conversions for a number of data formats Sure. Though, one of the drivers (mentioned in this thread) for having control over the de/serialization process was for performance. Converting to another format is going to obviously make this much worse. > as well as routing amongst numerous protocols, have a look at the > supported data formats page: http://camel.apache.org/data-format.html and > the transports http://camel.apache.org/transport.html > > This doesn't seem to be doing much more for the user than moving the work > they need to do around, Well, it abstracts the de/serialization process out of application code. > they still have to implement or configure the mechanics of the > transformation of the data format to the appropriate JMS message type and > back again. Even if you bake in something to the client to handle some > common formats you will quickly find that it doesn't meet everyone's needs > and you'll end up implementing a poor mans Camel inside a JMS API > restricted client which seems less than ideal. I agree reinventing the wheel (badly) is not a good idea. So, if Camel is able to provide us with a solution to the problem, that addresses the issues outlined here. Then, we should certainly look into it. Cheers. > > > >> >> On Thu, Jun 1, 2017 at 7:44 AM, Michael André Pearce < >>>> [email protected]> wrote: >>>> >>>> I think i might be getting the problem, use case you want to go for, >>>> which >>>> >>>>> 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, >>>>> and >>>>> 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 >>>>> its >>>>> 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="true"> >>>>> <xjc:serializable uid="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 >>>>> serializable >>>>> 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é Pearce < >>>>> [email protected]> 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 <[email protected]> >>>>>> wrote: >>>>>> On Wed, May 31, 2017 at 10:47 PM Michael André Pearce < >>>>>> >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>> Jms api dictates class set in object message to be serializable. >>>>>>> We could make an extension. It could be an extra message this >>>>>>> actually. >>>>>>> >>>>>>> >>>>>>> On 31 May 2017, at 22:37, Timothy Nodine <[email protected]> >>>>>>>> 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é 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’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 >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>> Clebert Suconic >>>>>>> >>>>>>> -- >>> Tim Bish >>> twitter: @tabish121 >>> blog: http://timbish.blogspot.com/ >>> >>> >>> > -- > Tim Bish > twitter: @tabish121 > blog: http://timbish.blogspot.com/ > >
