cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Kulp (JIRA)" <>
Subject [jira] Resolved: (CXF-1914) javax.xml.soap.SOAPMessage loses HTTP header information when passing through CXF Interceptors
Date Mon, 05 Oct 2009 16:28:31 GMT


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:
>             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="<>";
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.

View raw message