You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "Pieper, Aaron (SAIC)" <Pi...@Pragmatics.com> on 2008/05/16 15:12:45 UTC
RE: AttachmentDeserializer - handling attachments withquoted-printable content-transfer-encoding?
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:glen.mazza@verizon.net]
Sent: Friday, May 16, 2008 7:49 AM
To: users@cxf.apache.org
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
>
Re: AttachmentDeserializer - handling attachments withquoted-printable content-transfer-encoding?
Posted by Daniel Kulp <dk...@apache.org>.
Interesting, I'm not sure who's responsibility this is. Honestly, I
kind of would have expected the mail/activation framework maybe.
Then again, for streams, I'm not sure we're even leveraging that.
Actually, I'd like to also see what metro is doing with this.
In anycase, can you log a bug so this gets tracked?
Thanks!
Dan
On May 16, 2008, at 9:12 AM, Pieper, Aaron (SAIC) wrote:
> 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:glen.mazza@verizon.net]
> Sent: Friday, May 16, 2008 7:49 AM
> To: users@cxf.apache.org
> 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
>>
>
---
Daniel Kulp
dkulp@apache.org
http://www.dankulp.com/blog