I am using SoapUI to test a web service which is implemented using CXF 2.1. The service I am working on accepts both MTOM and non-MTOM attachments, and one kind of request SoapUI submits looks like this:
------=_Part_6_1979395.1210796510882 Content-Type: text/xml; charset=Cp1252 Content-Transfer-Encoding: quoted-printable Content-ID: 606517570647 <?xml version=3D"1.0" encoding=3D"UTF-8"?> <MyXml attribute=3D"value"> </MyXml> It's possible SoapUI generated is an illegal request, but it looks valid to me. SoapUI is indicating that the attachment was encoded, so CXF should decode it. The problem is that CXF 2.1 doesn't decode the attachment, so as a result the encoded XML gets passed through to my Java code. Assuming that it's CXF's responsibility to decode this attachment, the offending code segment appears to be the "setupAttachment" code in AttachmentDeserializer, which assumes the attachment is a raw mime body with no special encoding. I'm looking at fixing this by either patching AttachmentDeserializer to have a special case when it sees this type of encoding, or by patching MimeBodyPartInputStream to take the encoding type as an argument. Does this seem like a reasonable change, or am I overlooking something obvious? - Aaron
