This is why the proposal is for a pluggable interface to declared to convert from Object to byte[] and back not saying one moment Artemis owns or has all the implementations.
Anyhow your points are taken on board, we def need to agree on a well defined and clean api, to avoid exactly that situation. Sent from my iPhone > On 1 Jun 2017, at 17:59, Timothy Bish <[email protected]> wrote: > >> On 06/01/2017 12:49 PM, Michael André Pearce wrote: >> Not at all that's the point >> >> Application code uses JMS Api. The serdes are just defined/declared into the >> connection factory typically the only part of the app exposed to any >> particulars about the broker implementation detail. >> >> Yes we can do converter.convert(object) in code, this is just manual code in >> the app space. >> >> but like with kafka and I have to stress it's successfulness is that that >> converter is in it's api of the product. Which means a lot of companies >> reuse a few single implementations and a good eco system occurs like with >> schema registry (Eg we use confluents serdes we don't code out own) > > Which is exactly what camel can solve and without starting down the slippery > slop of packing the same data format conversions Camel can already handle > into the Artemis code base as will happen as each user wants their own > preferred data format. > > Similar things were tried in the ActiveMQ 5.x code and abandoned over time so > I'd like to avoid that if possible. > > Anyway, I've raised my objection. > >> >> >> >> Sent from my iPhone >> >>>> On 1 Jun 2017, at 17:39, Timothy Bish <[email protected]> wrote: >>>> >>>> On 06/01/2017 12:19 PM, Michael André Pearce wrote: >>>> Agreed it does as an EAI pattern or flow, But I have to code/define into >>>> Camel's dsl, it does JMS as much as our custom app code would it consumes >>>> the JMS api. >>> So you still need to code / define the serialization then and include that >>> in you application which means the difference between some >>> connection.setSerializationThing() vs >>> producer.send(Converter.convert(payload)); so I don't see how that is a >>> real value add to the JMS client. >>> >>>> What we propose here is just providing a clean way to define the JMS >>>> ObjectMessage internal serialisation. If Java serialisation isn't your cup >>>> of tea. (Which for many reasons isn't for us, and I'm sure it's similar >>>> for others) >>>> >>> >>> >>>>>> On 1 Jun 2017, at 16:58, Timothy Bish <[email protected]> wrote: >>>>>> >>>>>> On 06/01/2017 11:50 AM, Michael André Pearce wrote: >>>>>> Really this is much more about how an ObjectMessage serializes the >>>>>> Object. As we have C++ clients etc that obviously won't be able to >>>>>> understand Java serialized object. >>>>>> >>>>>> We use Avro and a schema repo for our dto transfer over the wire, it's >>>>>> been a real performance boost , and removed some core data issues, and >>>>>> really like to use it over the JMS land. >>>>>> >>>>>> One can argue that you could manually code this that you serialize the >>>>>> data manually first and then just manually send a BytesMessage. >>>>>> >>>>>> But I think taking some inspiration from other places where a serdes >>>>>> pattern is done has really helped (Kafka), from a corporation user >>>>>> approach wiring some prebuilt serdes into a factory is very easy, having >>>>>> duplicated code in many many apps leaves for issues, and implementation >>>>>> divergence. >>>>>> >>>>>> The one downside of Kafka is it's lack of spec api, this is one big sell >>>>>> of artemis as it's JMS compliant. Coding against JMS api for Java estate >>>>>> is a huge win, this is suggesting taking some of the good bits :). >>>>>> >>>>>> Does camel expose this as some sort of JMS API wrapper? I thought it was >>>>>> much more an EAI solution. >>>>>> >>>>>> Cheers >>>>>> Mike >>>>> Camel does JMS transport: http://camel.apache.org/sjms.html >>>>> Camel does AVRO: http://camel.apache.org/avro.html >>>>> >>>>> >>>>>> Sent from my iPhone >>>>>> >>>>>>>>> On 1 Jun 2017, at 15:18, Martyn Taylor <[email protected]> wrote: >>>>>>>>> >>>>>>>>> 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/ >>>>>>>> >>>>>>>> >>>>> -- >>>>> Tim Bish >>>>> twitter: @tabish121 >>>>> blog: http://timbish.blogspot.com/ >>>>> >>> -- >>> Tim Bish >>> twitter: @tabish121 >>> blog: http://timbish.blogspot.com/ >>> > > -- > Tim Bish > twitter: @tabish121 > blog: http://timbish.blogspot.com/ >
