[
https://issues.apache.org/jira/browse/CXF-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Seumas Soltysik updated CXF-4130:
---------------------------------
Attachment: cxf4130.patch
Patch includes system testcase which demonstrates the issue.
Suggestion of fix is included in the issue description but is not part of the
patch.
> Server using Provider implementation writes contents of SOAP body in SOAP
> header
> --------------------------------------------------------------------------------
>
> Key: CXF-4130
> URL: https://issues.apache.org/jira/browse/CXF-4130
> Project: CXF
> Issue Type: Bug
> Affects Versions: 2.5.2
> Reporter: Seumas Soltysik
> Fix For: 2.6
>
> Attachments: cxf4130.patch
>
>
> When using a server using a Provider implementation in conjunction with a
> WSDL that defines a SOAP header as part of its output, the contents out the
> SOAP body will be written as a SOAP header depending on the order of the
> parts defined in the output message.
> For example if an output message is defined like this:
> <message name="FooResponse">
> <part name="FooResponseHeader" element="tns:FooResponseHeader"/>
> <part name="FooResponse" element="tns:FooResponse"/>
> </message>
> and the SOAP binding operation is defined like this:
> <operation name="Foo">
> <soap:operation/>
> <input>
> <soap:header message="tns:FooRequest"
> part="FooRequestHeader" use="literal"/>
> <soap:body parts="FooRequest" use="literal"/>
> </input>
> <output>
> <soap:header message="tns:FooResponse"
> part="FooResponseHeader" use="literal"/>
> <soap:body use="literal"/>
> </output>
> </operation>
> because the FooResponseHeader is defined as the first part in the output
> message, CXF writes out the following message:
> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/";>
> <SOAP-ENV:Header>
> <FooResponseHeader
> xmlns:ns2="http://cxf.apache.org/soapheader/inband";>FooResponseHeader</FooResponseHeader>
> <ns2:FooResponse xmlns:ns2="http://cxf.apache.org/soapheader/inband";>
> <ns2:Return>Foo Response Body</ns2:Return>
> </ns2:FooResponse></SOAP-ENV:Header>
> <SOAP-ENV:Body/>
> </SOAP-ENV:Envelope>
> The basic reason for this is that the SoapOutInterceptor uses the part index
> of the part defining the output header to look up the instance of that part
> in the MessageContentList contained in the Message. However, in the Provider
> use case, the MessageModeOutInterceptorInternal interceptor puts the contents
> of the SOAP body into the first slot of the MessageContentList. So in the
> case where the index of the SOAP header part is 0, the contents of the SOAP
> body get written out as a SOAP header.
> Additional details are available as part of the CXF developers mailing list
> here:
> http://cxf.547215.n5.nabble.com/Response-SOAP-Headers-with-Provider-implementation-td5485785.html
> A possible solution to this problem is to place the contents of the SOAP body
> in the appropriate location in the MessageContentList in
> MessageModeOutInterceptorInternal. This solution would look something like
> this:
> MessageModeOutInterceptorInternal.handleMessage()
> list.remove(0);
> DocumentFragment frag =
> soapMessage.getSOAPPart().createDocumentFragment();
> try {
> Node body = soapMessage.getSOAPBody();
> Node nd = body.getFirstChild();
> while (nd != null) {
> body.removeChild(nd);
> frag.appendChild(nd);
> nd = soapMessage.getSOAPBody().getFirstChild();
> }
> int index = 0;
>
> Exchange exchange = message.getExchange();
> BindingOperationInfo operation =
> (BindingOperationInfo)exchange.get(BindingOperationInfo.class
> .getName());
> List<MessagePartInfo> parts = null;
> BindingMessageInfo bmsg = null;
> boolean client = isRequestor(message);
> if (!client) {
> if (operation.getOutput() != null) {
> bmsg = operation.getOutput();
> parts = bmsg.getMessageParts();
> }
> } else {
> bmsg = operation.getInput();
> parts = bmsg.getMessageParts();
> }
>
> if (parts != null && parts.size() > 0) {
> index = parts.get(0).getIndex();
> }
>
> list.set(index, frag);
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
