Hi Aki, I want to give you a more specific answer to your question. Suppose you have the following two routes:
route 1: Camel CXF consumer -> Camel CXF producer route 2: Camel CXF consumer -> some processor which returns an Input Stream -> Camel CXF producer There is a difference in the SOAP header handling between the two routes: - In the route 1, a SOAP header received by the CXF consumer will be forwarded in the CXF payload to the CXF producer so that the producer will sent out the SOAP header to a SOAP server. This will happen with and without the new patch. - In the route 2, the SOAP header received by the CXF consumer will not be forwarded to the CXF producer without the patch because the CXF payload object created by the CXF consumer is transformed to an Input Stream, so that the CXFproducer must create a new CXF payload. With the patch, however, the SOAP header will be forwarded in the Camel Header "org.apache.cxf.headers.Header.list" to the CXF producer which will send out the SOAP header. So in this case the Camel Header "org.apache.cxf.headers.Header.list" must be removed after the CXF consumer to achieve the old behavior. Best Regards Franz On Mon, Jul 27, 2015 at 1:21 PM, Franz Paul Forsthofer <emc2...@googlemail.com> wrote: > Hi Aki, > > there will be no change to the old behavior. Suppose you have the > following scenario: A SOAP client sends to a CAMEL CXF consumer and > this consumer just forwards the message to a Camel CXF provider which > calls a receiver SOAP server. If the SOAP client sends a SAP Header > then this header will also be forwarded to the CXF provider which just > forwards the header to the SOAP server. This happened before the patch > and the same will happen after the patch. > > Regards Franz > > > > On Fri, Jul 24, 2015 at 4:27 PM, Aki Yoshida <elak...@gmail.com> wrote: >> Hi Franz, >> I wanted to look at this but had not had time and a little late to comment. >> One question or concern that I had wasthat this would change the >> behavior of the existing tunneling scenarios using some soap headers, >> no? >> In other other words, some unwanted headers might tunnel through and >> show up at the other end? >> thanks. >> regards, aki >> >> 2015-07-21 12:44 GMT+02:00 Franz Paul Forsthofer <emc2...@googlemail.com>: >>> Hi, >>> >>> can I assume that there are no objections against the patch I proposed >>> in https://issues.apache.org/jira/browse/CAMEL-8978? >>> >>> Best Regards Franz >>> >>> On Fri, Jul 17, 2015 at 10:02 AM, Franz Paul Forsthofer >>> <emc2...@googlemail.com> wrote: >>>> Hi, >>>> >>>> Accessing the SOAP headers via the Camel header >>>> "org.apache.cxf.headers.Header.list" after a CXF consumer works fine, >>>> also for the CXF data format "PAYLOAD". >>>> >>>> However, currently the setting of SOAP headers via the Camel header >>>> "org.apache.cxf.headers.Header.list" is not working for a CXF producer >>>> with CXF data format "PAYLOAD". >>>> >>>> I found out that the list value contained in Camel header >>>> "org.apache.cxf.headers.Header.list" is correctly forwarded to the >>>> CXF request, however in the CxfEndpoint.CamelCxfClientImpl this list >>>> is overwritten by the value CxfPaylaod.getHeaders(). >>>> >>>> Therefore I propose to merge the values from the Camel header >>>> "org.apache.cxf.headers.Header.list" with the values of >>>> CxfPaylaod.getHeaders(). This has the advantage that you can set the >>>> headers either via the CxfPayload or by the Camel header >>>> "org.apache.cxf.headers.Header.list". >>>> >>>> For more details have a look at >>>> https://issues.apache.org/jira/browse/CAMEL-8978 >>>> >>>> Can somebody of the CXF experts comment whether my solution is >>>> feasible. Then I will commit the patch. >>>> >>>> Best Regards >>>> >>>> Franz Forsthofer
