On 28 February 2014 18:43, Fraser Adams <[email protected]>wrote:
> 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.
>
Yeah - basically to be JMS compliant you need to not have any fancy sort of
stuff in your list / map... So Our current thinking is probably that a
map/list that is intended to be seen as a JMS Map / Stream Message will
need to be carrying a specific message-annotation. We may additionally
want to allow people to set a property to allow their client to go
"off-spec" and have Map messages which contain Maps, Lists, etc... however
I think with JMS 2.0 this need is not as great... You can do getBody() and
get a Map bject back for a MapMessage and for an ObjectMessage that was
carrying a map...
>
> 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.
>
>
I think what we'll probably do is set some sort of synthetic application
property on the JMS message when it has been received as a AMQP object,
both identifying that that is the case, and possibly additionally (a
separate attribute) the type of the object.
>
> 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 :-/
>
>
>
The JMS Mapping will state clearly how a JMS client should handle any given
AMQP message.. and the Management specification should be clear on the
nature of the messages it sends. I definitely feel the pain however as I
am trying to get AMQP management to work over AMQP 0-9 and 0-10 in a way
which would be natural to the JMS client, and to other clients.... and the
List -> Map thing is gross :-)
>
> 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 of
> 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.
>
>
Yeah... I'm fairly relaxed - I do think the current solution is a nasty
hack :-) Personally I kind of hate having to use the body for the
attribute list in the request message... which is why I ponder the comma
separated list solution... But that doesn't fill me with any great love...
>
> 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)
>
>
I think you can get an RSS feed of the mailing list through markmail:
http://markmail.org/atom/list:org%2Eoasis-open%2Elists%2Eamqp+order:date-backwardwhich
would allow you to see any new documents being uploaded, or other
comments on the list
-- Rob
> Regards,
> Frase
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
