axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Adams (JIRA)" <>
Subject [jira] Commented: (AXIS2-4733) Incorrect content-type used in serialized SOAP message for an XML document attachment
Date Tue, 08 Jun 2010 05:07:11 GMT


Phil Adams commented on AXIS2-4733:

I don't quite understand the need for the extra changes you mentioned.   The AttachmentPartImpl
already supports getContentType()/setContentType() (inherited from javax.xml.soap.AttachmentPart),
so it already maintains the content type separate from the DataHandler instance (the DataHandler
has a getContentType() method but this returns only the implicit content type of the DataHandler's
data source; the user has no way to set the content type directly on the DataHandler but AttachmentPart
does provide that).

The reason that I made the changes only in the jaxws module is because the org.apache.axis2.jaxws.message.impl.MessageFactoryImpl
class processes AttachmentParts by adding just their DataHandler to the Message by calling
Message.addDataHandler().   This is the step where we essentially lose the content-type that
was stored on the AttachmentPart (which *could* be set by the user to a value that's different
from the implicit content type associated with the DataHandler).   So, by wrapping the AttachmentPart's
DataHandler at that point and storing the AttachmentPart's content type in the WrappedDataHandler,
we maintain the content type that was set in the AttachmentPart.

> Incorrect content-type used in serialized SOAP message for an XML document attachment
> -------------------------------------------------------------------------------------
>                 Key: AXIS2-4733
>                 URL:
>             Project: Axis2
>          Issue Type: Bug
>          Components: jaxws
>    Affects Versions: nightly
>            Reporter: Phil Adams
>            Assignee: Rich Scheuerle
>         Attachments: patch.txt
> When using the SAAJ API, a user could add an AttachmentPart to the SOAPMessage and explicitly
set the content type of the attachment by calling AttachmentPart.setContentType().   This
causes the AttachmentPart to maintain the user-specified content type separate from the content
type of the underlying DataHandler.    Within the jaxws module, the DataHandler instance is
saved away and then used to serialize the SOAP message, but we don't maintain the user-specified
content type.  Consequently, the DataHandler's content type is then used unconditionally when
serializing the MIME part in the output message.     Recently, the DataHandler class (or more
likely one of its underlying DataSource implementations) has started using a default content
type of "application/xml" for an XML document attachment.   This has caused a failure in a
Java EE CTS testcase, as the testcase explicitly sets the content type of the AttachmentPart
to "text/xml" and expects that to be used in the outgoing request message.   I'm including
a patch which fixes this problem by introducing a new "WrappedDataHandler" class which maintains
the content type from the AttachmentPart as well as the DataHandler instance.   This allows
for the correct content type to be used when serializing the message...

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message