Major Description
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!