Hi, Franz and I had an offline discussion about this and came to a conclusion that we introduce this behavior as default from camel 2.16.
Although this change may likely introduce a regression to some CXF to CXF Payload scenarios using WS extensions, an option to avoid this issue such as introducing a property-swtich to enable or disable this behavior or using a different header holder will introduce unnecessary complexity. In addition, the current SOAP header handling of CXF's Payload mode is not consistent with the other part of the header processing (i.e., POJO, Message, etc all transfer SOAP headers by default and all modes transfer the transport headers). So having this change, all headers SOAP or transport are now consistently transferred by default. In this way, there will be less confusion. To prevent the users from running into this changed behavior issue, we will add this information to the documentation. regards, aki 2015-07-27 13:54 GMT+02:00 Aki Yoshida <elak...@gmail.com>: > Hi Franz, > but the headers were transferred when you had the CXFPayload message > directly transferred from one end to the other, no? In other words, > that was the case when the scenario is really doing nothing at all > with the payload. But in a scenario where something between modifies > the payload coming in from one end and this modified payload is > forwarded to the other end, will your patch be now inserting the old > headers into the outgoing message? > regards, aki > > 2015-07-27 13:21 GMT+02:00 Franz Paul Forsthofer <emc2...@googlemail.com>: >> 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
