[
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="<[email protected]>"; 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.
