qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Re: OASIS AMQP Management specification wd06 comments
Date Fri, 28 Feb 2014 17:43:58 GMT
On 28/02/14 16:04, Rob Godfrey wrote:
> Hi Fraser,
> wd07 took out all the language about the form of bodies in repsonses I
> think :-)
> Jakub has already pointed out that the locales still used an illegal list
> (doh!).
> As to lists in the bodies... The JMS Mapping that Robbie is working on will
> define exactly how these get passed back.  Given the nature of the data an
> ObjectMessage is probably going to be the only sane way of doing so
> (there's no guarantee that any of the data within the inner lists is going
> to be valid for JMS Map messages... e.g. one of the "attributes" might
> itself have a list value).
Yippee!!! You might recall this, but one of my - many :-) - soap-boxes 
relates to issues of encoding AMQP Maps let alone AMQP Lists into JMS 
Message types. I've attached a thread from a year past January that was 
precipitated by changes to List encoding in Qpid 0.20 in that I said:

"Possibly the main reason using MapMessage is flawed though is because 
the JMS Spec says:
"A |MapMessage| object is used to send a set of name-value pairs. The 
names are |String| objects, and the values are *primitive data types in 
the Java programming language*", that's right "primitive data types". To 
be fair it then goes on to include byte[] in the list and it *does* 
include a getObject() and setObject(), but the JavaDoc explicitly says 
"This method works only for the objectified primitive object types 
(|Integer|, |Double|, |Long| ...), |String| objects, and byte arrays. "

If Robbie is looking at this it might be worth you guys looking through 
the whole thread "JMS List support & QMF2 - was Re: [ANNOUNCE] Apache 
Qpid 0.20 released" as it happens it was vaguely controversial and TBH I 
don't think at the time I was winning the ObjectMessage argument 
although what I was saying felt correct (to me).

I'm kind of glad you guys appear to be reaching a similar conclusion but 
given the discussions around it back then it's probably worthwhile 
giving the others involved an opportunity to reiterate their position.

One slight AMQP 1.0 related niggle with ObjectMessages I *think* that 
the AMQP 1.0 spec states a preference for not setting content-type 
("When using an application-data section with a section code other than 
data, content-type
SHOULD NOT be set."). I mention this because Gordon mentioned "the 
preferred method of sending maps and lists is through an AmqpValue 
section with the type encoded in the bytes making up that section" (see 
second attached mail).

Technically that would mean that according to the spec. for Map or List 
encoding the content-type should not be set. In itself it's probably not 
a big deal but I think that the implication is that one would need to 
use the slightly ugly (IMHO) instanceof in order to determine the actual 
type of the ObjectMessage.

This is one of those things that is likely to be "exciting" when trying 
to design applications that can interact with a range of broker 
versions. I already got bitten between 0.18 and 0.20 with the change of 
List representation then (and IIRC something changed between 0.8 and 
0.10 too). It's fairly easy to get things working consistently on trunk 
and forget that many people have a mixed economy of versions - though 
retaining backwards compatibility is hard I'd agree :-/

> I agree the attributes as a list on the message body inbound and the first
> row on the response message is a bit of a hack... I could personally live
> with a Map of { "attributes" -> <list of attributes>, "data" -> <list
> lists> }, or having attributes be a comma separated String in the
> application-properties.
I personally think the Map suggestion is cleaner. I did wonder about the 
comma separated string and it's *fairly* easy to "parse" though unless 
you explicitly disallow whitespace the regex to split the values becomes 
more fiddly and aside from that it feels kind of hacky too.

> I'll try to put out a WD08 shortly at least addressing the illegal locales
> thing.
> BTW WD07 can be downloaded here:
> https://www.oasis-open.org/committees/document.php?document_id=52286&wg_abbrev=amqp
> -- Rob
Cheers. Would you be able to post links to the working drafts when they 
get uploaded TBH I wasn't aware of WD07, the last link I saw was WD06 
(or is there a top level link that shows all the WDs to date)


View raw message