[jboss-jira] [JBoss JIRA] (WFLY-4393) Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers

[Takashi Nishigaya (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-4393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13045989#comment-13045989 ] 

Takashi Nishigaya commented on WFLY-4393:
-----------------------------------------

I found the following implementation in SOAPMessageContextImpl.java.

rt/frontend/jaxws/src/main/java/org/apache/cxf/jaxws/handler/soap/SOAPMessageContextImpl.java:
    public Object get(Object key) {
        Object o = super.get(key);
        if (MessageContext.HTTP_RESPONSE_HEADERS.equals(key)
            || MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
            Map<?, ?> mp = (Map<?, ?>)o;
            if (mp != null) {
                if (mp.isEmpty()) {
                    return null;
                }
                if (!isRequestor() && isOutbound() && MessageContext.HTTP_RESPONSE_HEADERS.equals(key)) {
                    return null;
                }
                if (isRequestor() && isOutbound() && MessageContext.HTTP_REQUEST_HEADERS.equals(key)) {
                    return null;
                }

It results in HTTP_REQUEST_HEADERS is always null, when the handler chain is in client-side outbound processing.
JSR224 spec does not apparently say when it is available. But I think it is not necessary to hide it, for compatibility with the Java SE default implementations.

> Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-4393
>                 URL: https://issues.jboss.org/browse/WFLY-4393
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 8.2.0.Final
>            Reporter: Takashi Nishigaya
>            Assignee: Alessio Soldano
>         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.



--
This message was sent by Atlassian JIRA
(v6.3.11#6341)