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:[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
---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog
