[
https://issues.apache.org/jira/browse/CXF-5550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned CXF-5550:
---------------------------------
Assignee: Freeman Fang
> CXF JAX-WS frontend DispatchImpl ignores setting of
> MessageContext.WSDL_OPERATION
> ---------------------------------------------------------------------------------
>
> Key: CXF-5550
> URL: https://issues.apache.org/jira/browse/CXF-5550
> 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
> 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
(v6.1.5#6160)
