[ 
https://issues.apache.org/jira/browse/CAMEL-8181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14259605#comment-14259605
 ] 

David Atkins commented on CAMEL-8181:
-------------------------------------

Hi Willem,

I didn't realise camel would convert the SOAPPart directly, so that's good to 
know!

Although the current behaviour isn't what I would expect, auditing to a log 
file is definitely a valid use case and changing this behaviour now would 
probably break backwards compatibility for others. Also, the current behaviour 
is consistent with how MESSAGE mode behaves. Therefore, i'm happy for this 
ticket to be rejected/won't fix. Also, this ticket's presence should help 
people in the future who have this issue.

Can I propose that we add some text to the documentation? The "Attachment 
Support" section doesn't currently mention CXF_MESSAGE mode. Could we maybe add 
the following?

"CXF_MESSAGE Mode: MTOM is supported, and Attachments can be retrieved by Camel 
Message APIs mentioned above. Note that when receiving a multipart (i.e. MTOM) 
message the default SOAPMessage to String converter will provide the complete 
multipart payload on the body. If you require just the SOAP XML as a String, 
you can set the message body with message.getSOAPPart(), and Camel convert can 
do the rest of work for you."

Thanks for your help,

David

> Default SOAPMessage to String Converter does not handle Multiparts as expected
> ------------------------------------------------------------------------------
>
>                 Key: CAMEL-8181
>                 URL: https://issues.apache.org/jira/browse/CAMEL-8181
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-cxf
>    Affects Versions: 2.14.1
>            Reporter: David Atkins
>            Assignee: Willem Jiang
>            Priority: Minor
>
> The default SOAPMessage to String converter in 
> org.apache.camel.component.cxf.converter.CxfConverter uses the 
> SoapMessage#writeTo method to convert it to a String. But when receiving a 
> multipart (e.g. when using MTOM) this provides all of the message parts, 
> instead of just the message body as expected, resulting in something like the 
> following appearing on the Exchange Body:
> {code}
> ------=_Part_0_715152323.1390739632718
> Content-Type: text/xml; charset=utf-8
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; 
> xmlns:rep="http://reportincident.example.camel.apache.org";>
>    <soapenv:Header>
>    </soapenv:Header>
>    <soapenv:Body>
>       <rep:inputReportIncident>
>          <incidentId>?</incidentId>
>          <incidentDate>?</incidentDate>
>          <givenName>?</givenName>
>          <familyName>?</familyName>
>          <summary>?</summary>
>          <details>?</details>
>          <email>?</email>
>          <phone>?</phone>
>       </rep:inputReportIncident>
>    </soapenv:Body>
>    </soapenv:Envelope>
> ------=_Part_0_715152323.1390739632718
> Content-Type: application/octet-stream; name=error.log
> Content-Disposition: attachment; name="error.log"; filename="error.log"
> Content-Transfer-Encoding: binary
> Content-ID: <error.log>
> file content here
> {code}
> I can't think of a useful use case for having the message in this format, 
> especially as the attachments are correctly added to the Exchange's 
> Attachment Map
> I believe the converter should only convert the initial Part to a String, 
> rather than the whole message. Something like this:
> {code}
> return XMLUtils.toString(new DOMSource(message.getSOAPPart()));
> {code}
> I'll try and find some time to create a patch next week
> Note that this is documented in the following Redhat support case : 
> https://access.redhat.com/solutions/740703 from a customer support issue I 
> raised a while back



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to