Hi Gordon Thanks for the interesting info. Will try to set encoding as UTF-8 in the C++ sender. Btw what are the possible valid values for Variant::setEncoding()? I assume UTF-8 is "UTF-8".
In our case we don't receive the string property in Java at all - it is not listed among the property names at all. Cheers Jiri On Sep 15, 2011 8:34 PM, "Fraser Adams" <[email protected]> wrote: > Hi Jiri > Out of curiosity have you looked at the type of the property. In other > words if you get the property and do a > myProperty.getClass().getCanonicalName(). > > I'll bet that it'll come back as a byte array rather than a String. I > believe that if you have control of the C++ client you might be able to > set the encoding to UTF-8 but if not... > > I've seen this loads as I've been implementing a Java implementation of > the QMF2 API. Frankly it's a pain in the backside. I've resorted to > defensive programming in my class that extracts String properties from > headers and Map messages as I've had some Agents send Strings and some > byte[]. > > /** > * There seem to be some inconsistencies where string properties are > sometimes returned as byte[] and > * sometimes as Strings. It seems to vary depending on the Agent and > getting it wrong results in > * ClassCastExceptions which is clearly unfortunate. > * > * This is basically a helper method to check the type of a property > and return the most "appropriate" > * String representation for it. > * > * @param p a property in Object form > * @return the most appropriate String representation of the property > */ > public static String getString(Object p) { > if (p == null) { > return ""; > } > if (p instanceof String) { > return (String)p; > } > if (p instanceof byte[]) { > return new String((byte[])p); > } > return p.toString(); > } > > My personal view is that the C++ client runtime should default to > sending string properties as UTF-8 encoded as this makes the default > behaviour interoperable. There might be a small performance gain from > not doing that, but in an end to end system of systems I suspect the > difference is very small and worth paying for interoperability. One > could always have a flag to switch off this behaviour, but I'd prefer > Strings to be UTF-8 encoded as a default (all IMHO of course). > > Hope this helps you out > Frase > > > > Jiri Krutil wrote: >> Hi >> >> When sending messages from a C++ client and receiving them in a Java client, >> we are having problems with custom message properties in the message header. >> String message properties set on the C++ sender side are not visible in the >> receiving Java app. Other property types seem to be processed fine. >> >> The C++ client is messaging v0.7, the Java client is 0.10. >> >> Any ideas? >> >> Cheers >> Jiri >> >> > > > --------------------------------------------------------------------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: mailto:[email protected] >
