On 01/29/2013 08:42 PM, Fraser Adams wrote:
I don't know about the specification document per se, but that JavaDoc for ObjectMessage says: "An |ObjectMessage| object is used to send a message that contains a serializable object in the Java programming language ("Java object")".Being pedantic :-) it says *a* serializable object not *any* serializable object, so I could argue that a Map containing any type that has a defined AMQP mapping to Java is also serializable, so does actually conform to the spec (unless there's something formal that actually does say *any* serializable Object).
I think the important question in questions of compliance with the spec is what might break.
I suspect that there are many applications using ObjectMessage that put other Serializable objects other than primitives, collections and strings. I would want such applications to continue to work using qpid, though obviously the encoded bytes of the message would likely only be usable in java receivers.
Likewise applications sending simple (non-nested) maps, should continue to work as expected. here we can quite legitimately encode them in the AMQP type system and that has the advantage of allowing non-java clients to participate in such conversations.
Where we would fail now is in providing the guarantee that a received MapMessage will never contain nested maps or lists. That could break some applications, though of course in those cases the application most likely wouldn't actually be able to process the message at all (unless of course they were additionally able to handle it as an ObjectMessage enclosing a map!). Having some means of turning on a strict interpretation would be nice. I.e. with that setting on such an incoming message could not be cast to a MapMessage. That may start making the code more complex of course, its an ideal though, I would say.
Of course I'm now just being facetious :-) I completely agree with the "provided you can explicitly control the encoding " I think ultimately that's the bit that's currently missing from the Java bindings, as we've already discussed. I think that it's good to have these conversations I find them really interesting (how sad am I). It's fascinating to get the perspective of others around interpretations of specifications etc. .
Agreed! [...]
That's fair enough <facetious>providing that it doesn't break code that was using the previous interface</facetious>
Agreed again. We didn't do a good enough job in thinking about backward compatibility and the impact of the change to existing users. I failed to mentally join up all the dots sufficiently and apologise for that. Glad it is all working again now though without too much work!
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
