You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by James Birdsall <jb...@microsoft.com> on 2014/08/21 04:29:56 UTC
Setting message annotations on send in AMQP 1.0
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?
Thanks!
--James
Re: Setting message annotations on send in AMQP 1.0
Posted by 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
>
>
RE: Setting message annotations on send in AMQP 1.0
Posted by James Birdsall <jb...@microsoft.com>.
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
Re: Setting message annotations on send in AMQP 1.0
Posted by Robbie Gemmell <ro...@gmail.com>.
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=amqp-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
> > >
> > >
> >
>
Re: Setting message annotations on send in AMQP 1.0
Posted by Rob Godfrey <ro...@gmail.com>.
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=amqp-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
> >
> >
>
Re: Setting message annotations on send in AMQP 1.0
Posted by Robbie Gemmell <ro...@gmail.com>.
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 <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
>
>
RE: Setting message annotations on send in AMQP 1.0
Posted by James Birdsall <jb...@microsoft.com>.
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
Re: Setting message annotations on send in AMQP 1.0
Posted by Rob Godfrey <ro...@gmail.com>.
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
>
>
RE: Setting message annotations on send in AMQP 1.0
Posted by James Birdsall <jb...@microsoft.com>.
---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
Re: Setting message annotations on send in AMQP 1.0
Posted by Gordon Sim <gs...@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?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org