Gordon, setting the property Variant encoding to 'utf8' does the trick, thanks for the hint.
Too bad that one has no chance of finding this in the docs. Having such interoperability issues between two clients of the same vendor is sad. I also agree that the defaults should be changed in a way that these thing 'just work' across languages. Will try to get the broker trace next week. Regards Jiri On Sep 16, 2011 2:49 PM, "Gordon Sim" <[email protected]> wrote: > On 09/16/2011 09:42 AM, Jiri Krutil wrote: >> Hi Fraser >> >> When I call Message.toString(), I see a list of all non-string properties, >> but there is no trace of the string properties I have set in C++. >> I think the difference in behaviour that we see could be explained by >> different versions of the C++ client or broker or Java client. >> >> I was experimenting with Variant.setEncoding() on the sending side, as >> Gordon suggested, but to no avail. Unfortunatelly there is no documentation >> for this function, so it's hard to guess what the supported encodings are. >> (I was trying encodings "str8" and "UTF-8", but this did not help. My string >> only contains plain 7-bit ASCII characters.) > > Yes, sorry about that, it does need addressed. The encoding you want is > utf8 (also recognised are utf16, binary and iso-8859-15). > >> By the way if the property value cannot be treated as a String in Java, I >> still don't see why is it not at least made available as a byte array. >> >> Let's wait and see if Gordon has something to say on this... > > Could you get a broker trace for a simple send and receive of such a > message? That might shed a clue at least as to which side the issue is on. > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] >
