cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Mattes (JIRA)" <>
Subject [jira] [Created] (CXF-5550) CXF JAX-WS frontend DispatchImpl ignores setting of MessageContext.WSDL_OPERATION
Date Fri, 07 Feb 2014 15:46:24 GMT
Andreas Mattes created CXF-5550:

             Summary: CXF JAX-WS frontend DispatchImpl ignores setting of MessageContext.WSDL_OPERATION
                 Key: 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

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