qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: JMS client skips string message properties
Date Wed, 21 Sep 2011 16:18:35 GMT
On 09/21/2011 04:20 PM, Fraser Adams wrote:
> I checked up on the producer client code and it's doing:
> message.getHeaders().setString("key", "value");
>
> where key and value are sensible things :-)

That essentially is the first of the two options listed. There is no 
checking or conversion. If the value was not valid utf8 then the message 
would be incorrectly encoded (and e,g the python and java client would 
be unable to decode it).

> With qpid::messaging my tests have done:
>
> message.setProperty("key", "value");
>
> The "setString" in qpid::client thus appears to populate UTF8 Strings
> (we're definitely having those interoperate with JMS consumers using
> UTF-8 Address Strings).
>
> Perhaps the simple option then is to modify the qpid::messaging API to
> be even more JMS like and be a bit more explicit in the method names
> with respect to the property types (perhaps it already supports this and
> I simply haven't noticed??

That is one option; we could add a method(s) that is more explicit as to 
the encoding of the value (I wouldn't want to remove the existing method 
and break the API). E.g.

   message.setUtf8Property("key", "value");

It would be clear that it is the applications responsibility to ensure 
that the data is indeed utf8.

A similar (and I think nicer) solution would be e.g

   message.setProperty("key", utf8("value"));

This is perhaps slightly less obvious than an explicitly named method 
but that could be addressed with some clear reference documentation for 
the method (needed anyway of the generic setProperty() remains unchanged).

Or as you suggested originally we could simply assume utf8 by default if 
no other encoding is specified in this context. I would lean to doing 
this without checking for the reasons mentioned in an earlier mail. The 
fact that this matches what the old API does is a fair sign that it will 
not cause great confusion!

---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org


Mime
View raw message