[jbossws-issues] [JBoss JIRA] (JBWS-3919) Client-side message context value HTTP_REQUEST_HEADERS is not shared between SOAP handlers

[Alessio Soldano (JIRA)]

     [ https://issues.jboss.org/browse/JBWS-3919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated JBWS-3919:
----------------------------------
              Project: JBoss Web Services  (was: WildFly)
                  Key: JBWS-3919  (was: WFLY-4393)
             Workflow: classic default workflow  (was: GIT Pull Request workflow )
    Affects Version/s:     (was: 8.2.0.Final)
          Component/s: jbossws-cxf
                           (was: Web Services)


> 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
>            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.15#6346)