On Wed, Sep 21, 2011 at 2:52 AM, Jiri Krutil <[email protected]> wrote: > Rajith > > I think this makes perfect sense from the JMS point of view and it also > works fine if all peers are Java clients.
> What I find quite surprising and unfortunate is that if a C++ client sends a > message to a Java client, the string message properties set by the C++ > client are not visible by default for the Java client. (They only become > visible if the C++ client sets the property encoding to "utf8".) > > IMHO this should work by default, especially if both client libraries are > from the same vendor. > (Not sure if it would be better to make the C++ client use the utf8 encoding > by default, or to change the Java client to map byte[] properties to > Strings.) The JMS client can't really treat all byte[] properties as Strings, as there could be properties that does need to be treated as "byte[]". IMO the C++ client should use a default encoding if a property is set as a String. Rajith > > Regards > Jiri > > > > On Tue, Sep 20, 2011 at 5:29 PM, Rajith Attapattu <[email protected]>wrote: > >> 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] >> >> > --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:[email protected]
