cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Freeman Fang (JIRA)" <>
Subject [jira] [Resolved] (CXF-5550) CXF JAX-WS frontend DispatchImpl ignores setting of MessageContext.WSDL_OPERATION
Date Thu, 13 Feb 2014 09:49:19 GMT


Freeman Fang resolved CXF-5550.

       Resolution: Fixed
    Fix Version/s: 2.6.14

patch applied on behalf of Andreas Mattes with thanks
added Apache license headers for xml|wsdl files for trunk for 2.7.x branch for 2.6.x branch

> CXF JAX-WS frontend DispatchImpl ignores setting of MessageContext.WSDL_OPERATION
> ---------------------------------------------------------------------------------
>                 Key: CXF-5550
>                 URL:
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-WS Runtime
>    Affects Versions: 2.7.8
>         Environment: Untyped JAX-WS clients using Dispatch.
>            Reporter: Andreas Mattes
>            Assignee: Freeman Fang
>             Fix For: 3.0.0-milestone2, 2.7.11, 2.6.14
>         Attachments: apache-cxf-2.7.8-src-patched-files.tar.gz, cxf-dispatch-fix.patch
> We have a service with a non-standard WSDL definition, where pairs of operations have
the same request payload, one operation is request-response for synchronous processing, one
operation is one-way for collection of request and later asynchronous processing. The request
payloads are provided as String or InputStream, and therefore the JAX-WS Dispatch shall be
used for service invocation. Setting the MessageContext.WSDL_OPERATION property, the service
invocation works properly unless WS-Addressing is activated.
> With WS-Addressing, however, the WSDL_OPERATION property is ignored for internal message
exchange setup, and the request is always treated as the one-way request, so that no response
is returned. Further analysis of the CXF DispatchImpl shows, that in this case the WSDL_OPERATION
property is overridden by the result of the lookup of a temporary request root element name
-> operation name table. In this case the 2nd operation definition with the same payload
root element wins, which in our case is the one-way version.
> This problem could be overcome by a simple processing change in DispatchImpl: When the
WSDL_OPERATION is explicitly set, and WS-Addressing is activated, the check of the payload
should be performed
> the other way round, i.e. the temporary map is created as operation name
> -> request payload root element name and verifies that the root element
> name corresponds to the operation name, even if the root element is not
> unique. If this check fails, behaviour falls back to the current one.

This message was sent by Atlassian JIRA

View raw message