So, erm, yeah...gawp...thought about book writing Fraser? ;) On 3 February 2014 19:53, Fraser Adams <[email protected]>wrote:
> On 03/02/14 15:38, Gordon Sim wrote: > >> >> Although AMQP itself does not place any restrictions on application >> property names, the selector syntax for AMQP 1.0 is that of JMS >> selectors[7], where as you noted, data-service is not a valid name. The >> extension of the selector explicitly states "JMS header names should be >> translated to amqp.<field_name> where <field_name> is the appropriate AMQP >> 1.0 field named in the table above, with the hyphen replaced by an >> underscore." >> >> However we could probably look at ways to (optionally?) make this more >> lenient. It certainly is also something that should be highlighted more >> prominently in documentation somehow. >> > It would be *really really good* to be able to make this more lenient > (would quoted field names be a possibility e.g. > 'data-service'='amqp-delivery')? > > I've used hyphened property names quite a lot and not being able to use > them would be a bit of a show stopper for me due to the integration issues > (I've got a lot of producers and they certainly couldn't all be changed > simultaneously) and given the apparent support at the moment for multiple > headers bindings between amq.match and a given queue I'm a bit stuck if I > want to migrate. > > > Re: "The extension of the selector explicitly states "JMS header names > should be translated to amqp.<field_name> where <field_name> is the > appropriate AMQP 1.0 field named in the table above, with the hyphen > replaced by an underscore." > > True, but that could be interpreted to mean the *standard* JMS header > names, and being slightly flippant it also says "The "properties" of the > JMS message are equivalent to the AMQP application-properties section" - > which simply says string. > Probably a case of different people reading things different ways, coupled with slightly ambiguous wording. My reading of that is that its saying anything that is a 'JMS Property' could be an 'AMQP application-properties' section entry, which doesnt (and cant) necessarily make the reverse true, but I agree the wording could have been clearer. The main thing to note though is that this particular filter was added in a section explicitly about JMS support, and as JMS properties aren't allowed "-" in their names this filter couldn't really say they can. What might be an option is making the filter more general than just supporting JMS semantics, or even defining another. JMS <-> AMQP mapping of property names (and values) is an interesting and annoying subject, and one that we have yet to fully cover in the JMS Mapping being worked on in the OASIS AMQP Bindings & Mapping TC.
