On Thu, Sep 15, 2011 at 2: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[].
Fraser, this is fixed now from 0.12 release onwards. See https://issues.apache.org/jira/browse/QPID-2930 for details. The getPropertyNames() will not return properties who's values are not legal as per the JMS spec. If you have properties with types like list, map or UUID it will not show up in the list. However you could still retrieve them using getObjectProperty(). Also if you print the message you will not see them. If you do a getStringProperty on a byte[] it will throw an exception. If you do a getStringProperty on a list or map it will just return you the toString() which is not useful IMO and for consistency we should throw an exception just like we do for byte[]. For UUID at least it makes sense, and you will get a toString() representation of the UUID. We now allow some AMQP specific properties to be retrieved via the getStringProperty method using custom property names. Ex. app-id using "x-amqp-0-10.app-id" routing-key using "x-amqp-0-10.routing-key" userid using "JMSXUserID" Regards, Rajith > /** > * 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]
