Re: Setting message annotations on send in AMQP 1.0

[Rob Godfrey <ro...@gmail.com>]

Hi James,

I've created a JIRA for this issue:
https://issues.apache.org/jira/browse/QPID-6065 and attached a patch
against the current trunk to the JIRA which I think represents what was
proposed here.  I've given the patch *very* minimal testing (i.e. I checked
I could set and receive both a message annotation and a delivery
annotation). Certainly if someone screws up their Json when setting the
properties they're not going to get very helpful error messages back... (I
hacked together my own Json parser to avoid having to add a dependency to
the JMS client).

Let me know if this looks like it will work for you.

Cheers,
Rob


On 22 August 2014 21:37, James Birdsall <jb...@microsoft.com> wrote:

> That's a good workaround for the '-' issue.
>
> Regarding not conflicting with client-owned annotations: supposing the
> work is done in MessageImpl.setStringProperty()? It looks like there are
> only three annotations which MessageImpl itself cares about:
> x-opt-{jms,to,reply}-type. setStringProperty() could look for the special
> property names Rob suggested, parse the JSON, throw away anything for those
> three reserved annotations, and put everything else in the map, overwriting
> previous values if present (so a user can update an annotation multiple
> times prior to sending). I don't know what the send path looks like, but I
> would assume that if the code there needs to set annotations it would
> overwrite.
>
> Retrieving annotations is much simpler: when getStringProperty() sees one
> of the special property names, it can grab the appropriate map and return a
> JSONified representation.
>
> If I can get some time today I will see about prototyping that.
>
> -----Original Message-----
> From: Robbie Gemmell [mailto:robbie.gemmell@gmail.com]
> Sent: Friday, August 22, 2014 4:15 AM
> To: users@qpid.apache.org
> Subject: Re: Setting message annotations on send in AMQP 1.0
>
> 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 <ro...@gmail.com> 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 <ro...@gmail.com>
> 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=amq
> > p-bindmap
> > >
> > >
> > > On 21 August 2014 20:36, James Birdsall <jb...@microsoft.com> 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:rob.j.godfrey@gmail.com]
> > > > Sent: Thursday, August 21, 2014 11:43 AM
> > > > To: users@qpid.apache.org
> > > > 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 <jb...@microsoft.com> wrote:
> > > >
> > > > > ---Original Message-----
> > > > > From: Gordon Sim [mailto:gsim@redhat.com]
> > > > > >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: users-unsubscribe@qpid.apache.org
> > > > > For additional commands, e-mail: users-help@qpid.apache.org
> > > > >
> > > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > --- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org For
> > > > additional commands, e-mail: users-help@qpid.apache.org
> > > >
> > > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>