After examining existing CXF testcases in the debugger, it appears that the processing of SOAP header elements and SOAP body elements in interceptors such as SoapOutInterceptor and the BareOutInterceptor depend on these elements being available in the MessageContentsList contained in the Message object. Both these interceptors match message part metadata with elements in the MessageContentsList and then writes out the data.
However, when a Provider implementation is used in MESSAGE mode, the MessageModeOutInterceptor takes all the elements in the SOAP body and associates them with a single document fragment which is then placed into the MessageContentsList. If the service as defined by the WSDL defines a response with multiple parts then this throws the processing of the SOAP body out of synch as interceptors such as the BareOutInterceptor try to match parts with elements in the MessageContentsList. In addition, the MessageModeOutInterceptor does not process the SOAP headers elements at all and therefore these elements are not placed in the MessageContentsList. As a result, when SOAP header elements are processed in the SoapOutInterceptor using part metadata, under certain conditions the SOAP body document fragment put into the MessageContentList is treated as a SOAP header and written out to the SOAP header element. None of this is caught as an issue by the runtime because the matching of message parts with elements in the MessageContentsList is all done based upon an index value in the message parts and not by matching meta data information in the parts with information in the contents of the MessageContentsList. I am looking for validation of my explanation as well as an explanation regarding why the MessageModeOutInterceptor handles the SOAP message in this manner. Regards, Seumas Soltysik -- View this message in context: http://cxf.547215.n5.nabble.com/Response-SOAP-Headers-with-Provider-implementation-tp5485785p5490358.html Sent from the cxf-dev mailing list archive at Nabble.com.
