A camel-cxf endpoint, with datatype MESSAGE or PAYLOAD, fails to populate the Exchange message body correctly, when the endpoint is consuming from a JMS destination, and the SOAP message body is encoded with UTF-8, and the body contains certain multi-byte characters. The problem only arises on Windows, and can only be shown on Fuse 6.2.1 with hot-fix HF6 applied. Without HF6, the message body ends up null.

The characters that are known to cause problems include the following, but this is probably not an exhaustive list:

U+00A2 ¢ c2 a2 CENT SIGN
U+00A3 £ c2 a3 POUND SIGN
U+00A4 ¤ c2 a4 CURRENCY SIGN
U+00A5 ¥ c2 a5 YEN SIGN
U+00A6 ¦ c2 a6 BROKEN BAR
U+00A7 § c2 a7 SECTION SIGN
U+00A8 ¨ c2 a8 DIAERESIS

It might be, in fact, that any multi-byte UTF-8 character is problematic – I have not been able to figure this out yet.

It seems that, at some point during the processing of the UTF-8 data stream, the initial "C2" byte gets stripped, leaving an invalid, one-byte character.

The customer's test case fails because it attempts to apply an <xpath> operation to the message body after processing by camel-cxf. However, close inspection of the Fuse log (with a hex editor) shows that the message body logged by camel-cxf contains the invalid character; the problem with <xpath> is simply a consequence of the broken message body.