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