Return-Path: 
 <issues-return-20256-apmail-cxf-issues-archive=cxf.apache.org@cxf.apache.org>
X-Original-To: apmail-cxf-issues-archive@www.apache.org
Delivered-To: apmail-cxf-issues-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 4A10E9C1E
	for <apmail-cxf-issues-archive@www.apache.org>;
 Fri,  2 Mar 2012 21:16:20 +0000 (UTC)
Received: (qmail 48376 invoked by uid 500); 2 Mar 2012 21:16:20 -0000
Delivered-To: apmail-cxf-issues-archive@cxf.apache.org
Received: (qmail 48324 invoked by uid 500); 2 Mar 2012 21:16:20 -0000
Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:issues-help@cxf.apache.org>
List-Unsubscribe: <mailto:issues-unsubscribe@cxf.apache.org>
List-Post: <mailto:issues@cxf.apache.org>
List-Id: <issues.cxf.apache.org>
Reply-To: dev@cxf.apache.org
Delivered-To: mailing list issues@cxf.apache.org
Received: (qmail 48311 invoked by uid 99); 2 Mar 2012 21:16:20 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Mar 2012 21:16:20 +0000
X-ASF-Spam-Status: No, hits=-1998.7 required=5.0
	tests=ALL_TRUSTED,T_RP_MATCHES_RCVD,URI_HEX
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Mar 2012 21:16:18 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
	by hel.zones.apache.org (Postfix) with ESMTP id AFE7B573B
	for <issues@cxf.apache.org>; Fri,  2 Mar 2012 21:15:58 +0000 (UTC)
Date: Fri, 2 Mar 2012 21:15:58 +0000 (UTC)
From: "Daniel Kulp (Resolved) (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: 
 <590488654.14018.1330722958722.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1658530639.5363.1329936708822.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (CXF-4130) Server using Provider implementation
 writes contents of SOAP body in SOAP header
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394
X-Virus-Checked: Checked by ClamAV on apache.org


     [ https://issues.apache.org/jira/browse/CXF-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-4130.
------------------------------

       Resolution: Fixed
    Fix Version/s:     (was: 2.6)
                   2.5.3
                   2.4.7
                   2.3.10
         Assignee: Daniel Kulp
    
> 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
>            Assignee: Daniel Kulp
>             Fix For: 2.3.10, 2.4.7, 2.5.3
>
>         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