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] > >
