chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vyacheslav Pascarel <>
Subject Web Services binding failure in Chemistry 0.14 client while passing customized SOAP Security header
Date Fri, 30 Sep 2016 15:37:08 GMT

I have a custom authentication provider that extends org.apache.chemistry.opencmis.client.bindings.spi.StandardAuthenticationProvider.
The provider modifies Security header in outgoing SOAP message in order to implement a proprietary
authentication. On the server side authentication data is parsed, client is authenticated,
request is processed and a new Security header is attached to the reply message. The client
extract authentication data from the response and uses it for sequential calls. That worked
well in implementations based on Chemistry 0.10 and 0.13. While trying to port to Chemistry
0.14 the code started to fail with java.lang.UnsupportedOperationException. Using debugger
I found the cause of the failure:

1.       When message is being prepared to be sent Chemistry framework calls a custom authentication
provider. The provide prepares Security header and returns it to framework

2.       Framework in org.apache.chemistry.opencmis.client.bindings.spi.webservices.CXFPortProvider.
createPortObject(...) creates a new header list and adds it to request context at line 120:



     Collections.singletonList(new Header(new QName(soapHeader.getNamespaceURI(), soapHeader

            .getLocalName()), soapHeader)));

3.       Request is sent to server, server processes it and replies with a message containing
another Security header

4.       Response is being processed on client by Apache CXF making bunch of calls to interceptors.
One of the interceptors, org.apache.cxf.binding.soap.saaj.AAJInInterceptor.replaceHeaders(...),
attempts to replaces old headers in context if the response has headers with matching names
(line 310):

Header oldHdr = message.getHeader(

new QName(elem.getNamespaceURI(), elem.getLocalName()));

if (oldHdr != null) {




The problem is that the header list created by CXFPortProvider in step#2 is read-only, but
AAJInInterceptor in step #4 expects it to be read-write.

Not sure where the fix has to be done, but I would expect that having the same header in the
request and response is acceptable.


Vyacheslav Pascarel

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message