The problem exists both in CXF versions 2.0.4 and 2.1. Geronimo provides a QuotedPrintableInputStream which I will leverage to handle the transformation, the creation of a DOM should not be necessary.
- Aaron -----Original Message----- From: Glen Mazza [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 7:49 AM To: [email protected] Subject: Re: AttachmentDeserializer - handling attachments withquoted-printable content-transfer-encoding? Hi Aaron. Something you're vague on below is whether the code works with 2.0.x, did you test if it does? That would indicate a bug in 2.1 that could probably easily be fixed. As for the encoding, I believe you're referring to replacing the "<"'s with "<", etc., correct? Pardon this shot in the dark until you get a more substantive answer, but you might wish to add a SAAJInInterceptor[1] on the provider side before processing--as that creates a DOM first, I suppose that would force the decoding of the XML string. Still, I'm not sure if this decoding would occur with attachments (like it would for the regular SOAP body), and there is a also a general performance issue in creating the DOM to begin with. Nonetheless, perhaps there is code that could be leveraged here to provide a decoding solution. Glen [1] http://cwiki.apache.org/CXF20DOC/ws-security.html#WS-Security-Configurin gtheWSS4JInterceptors 2008-05-15 Pieper, Aaron (SAIC) wrote: > 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 >
