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:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
