Yes, I also like this. JSON encoding of individual properties is a thought I had, but this is more appealing and sidesteps the naming issue more cleanly.
One issue may be that there are annotations that the client itself will need to set on individual messages, which setting of these properties probably shouldnt be allowed to interfere with in some (if not all) cases. We can always handle those explicitly though, e.g reserving those names and/or requiring something like "annotation <foo> not being present in the application-provided encoding must not result in them being removed from the underlying annotations map". Robbie On 22 August 2014 11:56, Rob Godfrey <[email protected]> wrote: > Rather than having to create an extra property for each annotation, how > about we define two annotations > > JMS_AMQP_MESSAGE_ANNOTATIONS and JMS_AMQP_DELIVERY_ANNOTATIONS > > and we say that the value associated with these properties (if present) > should be a JSON string representing a map. > > Let's say you want to send a message annotation with an annotation x-foo > with value int 5 and an annotation of x-bar with value string "wibble". > > We could represent this as a JSON string: { "x-foo" : 5, "x-bar" : > "wibble" } > > This will work fine as long as the only values you want to sent are of type > string, int or boolean (or lists containing only values of those types). > For other types (unsignedlongs, symbols, arrays, etc) I think we would > want to define an encoding scheme into JSON objects... However if James > onlys needs Strings and ints at the moment, this can be worked out in > detail later (though I have some ideas). > > How does this appeal? > > -- Rob > > > On 22 August 2014 11:40, Robbie Gemmell <[email protected]> wrote: > > > Hi James, > > > > As Rob suggested, the initial thinking for the JMS <-> AMQP mapping > > document on handling the annotations was to do something with JMS message > > properties, through special naming convention and possibly values, > > converting those into a symbol keyed entry (string keys arent allowed) in > > the relevant annotations map of the underlying amqp message, and > similarly > > in the other direction. > > > > The are some problems with the suggestion of using > > "amqp.annotation.x-opt-offset" unfortunately. Primarily, both "." and "-" > > are illegal charactes in JMS property names and so can't be used (they > > would likely break interop if they were; it is a requirement of JMS to be > > able to send one providers messages using another, so if a particular > > provider implementation were to be lenient here, another which was > adhering > > to the restriction would then be unable to send its message objects). See > > the 'Identifiers' info in the Message Selectors section of > > http://docs.oracle.com/javaee/7/api/javax/jms/Message.html for the full > > naming restrictions. > > > > Also, however unlikely it seems that it should clash, property names that > > dont begin "JMS" are all in the same space as JMS application properties > > and so we cant really reserve them in the mapping document. Message > > properties that begin "JMS_" are however considered to be > > provider-specific, with "JMS_<vendor>_" typically being used to further > > segment this. As such, any special properties defined by the mapping are > > currently prefixed "JMS_AMQP_" to distinguish them, so we could begin the > > property names that define message and delivery annotations with a > > particular prefix of JMS_AMQP_MSG_ANN_ and JMS_AMQP_DLV_ANN_ for example. > > > > I haven't yet really thought through beyond this how we would reversibly > > map particular amqp annotation names/values into particular JMS property > > names/values. Open to suggestions. > > > > Robbie > > > > > > As an aside, for those that are not members of Oasis or the AMQP Bindings > > and Mappings TC in particular. > > > > The current working draft (5) of theJMS mapping document is viewable at > > the following public URL: > > > > > https://www.oasis-open.org/committees/download.php/53086/amqp-bindmap-jms-v1.0-wd05.pdf > > > > Comments by non-members can be posted to the public comments mailing > list, > > see the following for details: > > > > > https://www.oasis-open.org/committees/comments/index.php?wg_abbrev=amqp-bindmap > > > > > > On 21 August 2014 20:36, James Birdsall <[email protected]> wrote: > > > > > We're only looking at strings and int types, at least right now. In > this > > > specific instance, I need to set an annotation named > > "x-opt-partition-key" > > > to some string. > > > > > > If we're talking long-term, then an easier way to retrieve annotations > on > > > received messages would be nice, too. It looks like I can get a list of > > > Sections via Message.getPayload, search for a Section which is a > > > MessageAnnotations, and get the Map out of that -- but that's hardly > > > implementation-independent! > > > > > > I'm told that we can already filter on annotations at receive time, > using > > > the syntax amqp.annotation.annotationname (e.g. > > > "amqp.annotation.x-opt-offset > '-1'"). Using the same naming > convention > > > via the standard application properties getter/setter seems like an > > obvious > > > way to go. > > > > > > -----Original Message----- > > > From: Rob Godfrey [mailto:[email protected]] > > > Sent: Thursday, August 21, 2014 11:43 AM > > > To: [email protected] > > > Subject: Re: Setting message annotations on send in AMQP 1.0 > > > > > > Hi James, > > > > > > I think the best thing would be to try to do something inline with the > > > where the AMQP 1.0 JMS Mapping is going. In particular that is trying > to > > > ensure that people never have to use API outside of the standard JMS > API > > - > > > by doing this you'll also be future proofing your users against us > > changing > > > the underlying implementation of the client in the future. > > > > > > I think the way we would be looking to achieve this is by using a > special > > > naming convention in the standard application properties to send and > > > receive delivery and message annotations. > > > > > > Robbie Gemmell is leading the AMQP <-> JMS effort - perhaps he can give > > us > > > a steer / start mocking up how we are going to achieve this in the > future > > > specification. > > > > > > Also, what sort of values are you looking to put into the annotations - > > > will they be Strings / ints / other basic types or are you looking to > > send > > > more complicated AMQP structured content? > > > > > > Cheers, > > > Rob > > > > > > > > > On 21 August 2014 19:51, James Birdsall <[email protected]> wrote: > > > > > > > ---Original Message----- > > > > From: Gordon Sim [mailto:[email protected]] > > > > >On 08/21/2014 03:29 AM, James Birdsall wrote: > > > > >> For interop, I need to put values into the message annotations > when > > > > sending a message, but that doesn't seem to be possible. Annotations > > > > can be set via message constructors, but those are not public, and > the > > > > public message create functions in Session/SessionImpl do not offer a > > > > way to pass annotation values. And then once you have a message > > > > object, there are no setters that put values in the map. Short of > > > > hacking setStringAnnotation() into MessageImpl, I think I'm stuck. > Have > > > I missed something? > > > > > > > > >Which API is this with? > > > > > > > > This is the JMS AMQP 1.0 client. We (Azure ServiceBus) have customers > > > > using/who want to use the Qpid JMS client with our AMQP 1.0 support > > > > and I'm trying to prepare samples to show how to use some of our > newest > > > features. > > > > > > > > If I'm right, is there any philosophical objection to adding > > > > MessageImpl.setStringAnnotation() or the equivalent? I'm willing to > do > > > > the coding and testing and submit a patch. Telling customers that the > > > > feature will be accessible in 0.32 (or whenever) is a better story > > > > than just "sorry". > > > > > > > > --James > > > > > > > > --------------------------------------------------------------------- > > > > 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] > > > > > > > > >
