]
Alessio Soldano commented on JBWS-3919:
---------------------------------------
This could simply be a bug in those cxf lines or because of a TCK check actually requiring
it. We'll figure out what can be done.
Client-side message context value HTTP_REQUEST_HEADERS is not shared
between SOAP handlers
------------------------------------------------------------------------------------------
Key: JBWS-3919
URL:
https://issues.jboss.org/browse/JBWS-3919
Project: JBoss Web Services
Issue Type: Bug
Components: jbossws-cxf
Reporter: Takashi Nishigaya
Fix For: jbossws-cxf-5.1
Attachments: handler_header_chain.zip
CXF runtime does NOT propagate JAX-WS standard context value
MessageContext.HTTP_REQUEST_HEADERS to the subsequent client-side SOAP handlers. For
instance,
1. The first client handler puts the newly created HTTP request header map that contains
the custom header 'foo' in the message context.
2. The second client handler can not refer to the custom header 'foo' added in
the step 1. The HTTP request header map in the message context is null.
The weird thing is that the custom header added in the step 1 is correctly received by
the server-side web services.
The both of Java SE default JAX-WS implementations and GlassFish correctly share
HTTP_REQUEST_HEADERS map between handlers.
Please check the attached test case and compare the two test case. The method
testHandlerChainOnServer() tests the case that the client is running on the container. On
the other hand, testHandlerChainOnStandalone() tests the standalone client case.
In order to reproduce the issue:
$ mvm clean test -P wildly-managed (or -P wildly-remote)
Additionally, this behavior is the same in EAP 6.3.3.