Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Message-ID: <818595615.1254760111460.JavaMail.jira@brutus>
Date: Mon, 5 Oct 2009 09:28:31 -0700 (PDT)
From: "Daniel Kulp (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Subject: [jira] Resolved: (CXF-1914) javax.xml.soap.SOAPMessage loses HTTP
 header information when passing through CXF Interceptors
In-Reply-To: <2134014349.1226633324245.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Daniel Kulp resolved CXF-1914.
------------------------------

       Resolution: Fixed
    Fix Version/s: 2.2.2


This was resolved in CXF 2.2.2 as part of the big provider/dispatch refactor that  resulted in that interceptor being completely removed.

> javax.xml.soap.SOAPMessage loses HTTP header information when passing through CXF Interceptors
> ----------------------------------------------------------------------------------------------
>
>                 Key: CXF-1914
>                 URL: https://issues.apache.org/jira/browse/CXF-1914
>             Project: CXF
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 2.1.3
>         Environment: Any
>            Reporter: Jason Royals
>             Fix For: 2.2.2
>
>
> We are using Camel with CXF to enable a lightwight ESB-like integration solution.  One of the services we are proxying requires a binary Soap attachment and so we need to consume and resend the multipart HTTP request, and the headers to support it.
> We pass in a HTTP request with the following headers:
>  Content-Length: 221357
>  SOAPAction: ""
>  Content-Type: multipart/related; type="application/xop+xml"; start="<rootpart@soapui.org>"; start-info="text/xml"; boundary="----=_Part_3_21579068.1226633091650" 
>  MIME-Version: 1.0
> But when Camel gets it, the headers have been discarded and replaced with only "Content-Type: text/xml; charset=utf-8"
> After a few hours debugging, the problem seems to be that:
> * DispatchInDatabindingInterceptor creates the java.xml.soap.SOAPMessage correctly using the InputStream from the request, and adds it to a org.apache.cxf.message.Message object
> * DispatchInDatabindingInterceptor$PostDispatchSOAPHandlerInterceptor removes the SOAPMessage object from org.apache.cxf.message.Message and converts it into a javax.xml.transform.Source, and puts that into the org.apache.cxf.message.Message object
> * DispatchInDatabindingInterceptor$PostDispatchLogicalHandlerInterceptor removes the javax.xml.transform.Source and re-creates the java.xml.soap.SOAPMessage again using the Source, and puts it into the org.apache.cxf.message.Message object
> Converting to a Source loses the original header information, so the new SOAPMessage created from that Source only has the default headers. This is a problem for us, and others requiring the HTTP headers to be passed through intact from CXF.
> If I get some time on the weekend I'll write a test to expose it. 
> Thanks!

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