Hi Fraser When I call Message.toString(), I see a list of all non-string properties, but there is no trace of the string properties I have set in C++. I think the difference in behaviour that we see could be explained by different versions of the C++ client or broker or Java client.
I was experimenting with Variant.setEncoding() on the sending side, as Gordon suggested, but to no avail. Unfortunatelly there is no documentation for this function, so it's hard to guess what the supported encodings are. (I was trying encodings "str8" and "UTF-8", but this did not help. My string only contains plain 7-bit ASCII characters.) By the way if the property value cannot be treated as a String in Java, I still don't see why is it not at least made available as a byte array. Let's wait and see if Gordon has something to say on this... Cheers Jiri On Fri, Sep 16, 2011 at 10:29 AM, Fraser Adams < [email protected]> wrote: > Hi Jiri > You say "In our case we don't receive the string property in Java at all" > > I think that this could possibly be a separate issue. In the scenario I'm > referring to to try and emulate your problem I have some test C++ code like: > > for (int i = 0; i < NUMBER_OF_ITERATIONS; i++) { > char* buffer = new char[50000]; > Message message(buffer, 50000); > if ((i % 3) == 0) message.setProperty("item-**owner", > "jdadams"); > else message.setProperty("item-**owner", "fadams"); > > message.setProperty("data-**service", "amqp-delivery"); > > sender.send(message); > etc..... > > In my Java ItemConsumer MessageListener I have. > > public void onMessage(Message message) { > try { > BytesMessage msg = (BytesMessage)message; > > byte[] buffer = new byte[(int)msg.getBodyLength()]**; > msg.readBytes(buffer); > > System.out.println(msg.**getStringProperty("item-owner"**)); > System.out.println(msg.**getStringProperty("data-**service")); > > > I get ClassCast Exceptions "failed as value of type class [B is an array", > which is consistent with what I've seen in the past and why I ended up > resorting to the defensive getString() method I posted the other day. > > Have you tried a System.out.println(message) to see what Message.toString() > tells you? You might get some more pointers by doing that. > > Using my test C++ above it looks like the "key" part of it actually does > get set to UTF-8 by the C++ client runtime, but the default for the "value" > part doesn't seem to do this. It's *just possible" that something you've > done might have caused the property key to be non-UTF-8 too - clearly if the > key ends up as a byte array on the Java side then you won't see the > property. I'm not at all sure that this is what's happening in your case, > but it's worth a look and Message.toString() might give you a pointer. > > > Sorry I can't be more help at this stage. > Regards > > Frase > > > Jiri Krutil 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. >> >> 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:users-subscribe@qpid.**apache.org<[email protected]> >>> >>> >>> >> >> >> > > > ------------------------------**------------------------------**--------- > Apache Qpid - AMQP Messaging Implementation > Project: http://qpid.apache.org > Use/Interact: > mailto:users-subscribe@qpid.**apache.org<[email protected]> > >
