An alternative line to take is to make setting the encoding more obvious
(e.g. by ensuring our examples do so, which they currently do not) and
perhaps simpler. Or we could allow assignment of std::wstring, arguably
closer in role to java.lang.String, and encourage people to use that for
textual data.
Gordon do you remember in a previous post to the related thread on
headers exchange (lack of) interoperability I mentioned that fortunately
we haven't been bitten too hard in my organisation (yet) because we
happen to still be using the qpid::client API.
I checked up on the producer client code and it's doing:
message.getHeaders().setString("key", "value");
where key and value are sensible things :-)
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??)
Regards,
Frase
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
