On Thu, Sep 15, 2011 at 2:55 PM, Jiri Krutil <[email protected]> wrote: > 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.
This is done deliberately - if you do a getPropertyNames(), the names of properties who's types that are not legal as per the JMS spec are not included. As Gordon mentioned, if you don't set an encoding I believe the C++ side encodes it as a byte[], which is not a valid JMS type. > 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] >> > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
