Hi Gordon,
It's true that ObjectMessage allows for the possibility of any
serializable object, what I'm talking about here is using that to
facilitate java.util.Map to be sent as an amqp/map and java.util.List to
be sent as an amqp/list. To be fair I don't think that this feels any
different than any other mapping e.g. for ints, longs etc. and frankly
as we've previously discussed we've also got awkwardness with String
interoperability (String, byte[] depending on whether utf8 is specified
in C++ clients).
So whilst I agree to some extent that there's a potential for
misunderstanding I don't see that as any worse than saying we're using
MapMessage to expose amqp/map. At the very least at least it will
conform to the JMS spec because java.util.Map and java.util.List are
both serializable. And as I say there's implicit guidance in the JavaDoc
that ObjectMessage is the way to go for transporting collections.
To be honest better exposing the AMQP Content-Type would help with any
ambiguity, for example a pattern of explicitly setting the Content-Type
of amqp/list and using a java.util.List as the payload of a
javax.jms.ObjectMessage - and similarly for amqp/map and java.util.Map
is IMHO exactly analogous to what one would do in qpid::messaging with
the Content Type and Variant::List and Variant::Map. I really like the
idea of consistent usage patterns between qpid::messaging and JMS. The
APIs are already extremely similar so promoting this sort of pattern
seems like a good idea in my book.
Re "is not driven from a love of those interfaces, but from the fact
that they are already defined and there may be applications using them
or developers used to working with them. " I feel a sense of irony
coming on here given my experiences over the weekend :-D
I've got some sympathy with this view - from a perspective of decoding
it's not too hard to write defensive code to be able to handle a
reasonable set of variations, that's what I did at in my code where I
checked the Content-Type so was able to figure out that the MapMessage
that I was getting was really a list. On the encoding side that's where
it'd be good for the runtime to be able to be tolerant so if I send a
BytesMessage with amqp/list it behaves as it did, or a MapMessage with
amqp/list it behaves as 0.20 and (hopefully) in the future if I send and
ObjectMessage containing a List with a Content-Type of amqp/list then
that would work too.
I think that exposing the AMQP Content-Type more satisfactorily is very
much our friend from the perspective of interoperability.
I still assert that ObjectMessage is the only way to expose amqp/map and
amqp/list and properly conform to the spec. Just because we might want
to introduce a constraint that only Maps and Lists (and other types with
an AMQP serialisation) are supported here and not arbitrary Java objects
isn't a huge constraint (especially if it's documented). And still feels
IMHO ultimately the most consistent model for passing Collections.
Frase.
On 29/01/13 17:34, Gordon Sim wrote:
On 01/26/2013 03:43 PM, Fraser Adams wrote:
I've said the following a couple of times on the Qpid Users mailing
list, but nobody has yet bitten, hopefully this issue might start the
discussion again....
IMHO the *only* correct way to expose amqp/map or amqp/list in JMS in a
way that doesn't break the JMS specification is to use
javax.jms.ObjectMessage.
My concern, at least on the sending side, is that people expect java
serialization to be used with such messages and therefore expect to be
able to use arbitrary java objects with it (as well as relying on e.g.
custom readObject()/writeObject()/readExternal()/writeExternal()
methods).
While I think that an AMQP encoding for general objects is an
interesting avenue to consider[1], its a larger problem than simply
handling (potentially recursive) maps and lists of primitive types.
The use of MapMessage and StreamMessage is not driven from a love of
those interfaces, but from the fact that they are already defined and
there may be applications using them or developers used to working
with them.
It is true we don't enforce that lists/maps are non-recursive and that
is strictly violating the standard. That fact is noted in the
documentation. It would probably be nice to have a way to enable
strict compliance as well. It is certainly an issue for QMF messages,
which do contain nested lists and maps, but it might not be for other
uses.
Likewise however encoding ObjectMessages as an amqp/map rather than
using serialization to generate the sequence of bytes might be
considered a violation of the specification also.
What we have is certainly not perfect. The JMS API itself is not
perfect here.
The idea was to allow AMQP encoded data to be accessed via a variety
of interfaces so you can pick the one you prefer. Extending the
current options such that a map or list encoded message could also be
accessed as an ObjectMessage seems like a reasonable enhancement to me.
The sending side has the added issue of needing to infer the desired
encoding in some way. If you allow different encodings for a
particular Message type then you need some other explicit way to
choose between them.
--Gordon.
[1] AMQP 1.0 provides annotations that could be used to indicate class
in a standard way.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
