Handling of WSDL_OPERATION property in CXF impl of JAX-WS Dispatch

[Andreas Mattes <am...@talend.com>]

Hi,

In a customer project, we have the following issue:

There are services with non-standard WSDL definitions, 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.

As we assume that there may be more cases with similar situations, and with explicit setting of the WSDL_OPERATION, the expected behaviour is that this hint is not overridden unless it is really inconsistent, we would file a Jira issue with a proposed fix.

Kind regards,

Andreas Mattes

Talend Germany

Re: Handling of WSDL_OPERATION property in CXF impl of JAX-WS Dispatch

[Andreas Mattes <am...@talend.com>]

Thanks, I've done so (https://issues.apache.org/jira/browse/CXF-5550).

Regards,

Andreas Mattes

Talend Germany


Am 10.02.2014 06:31, schrieb Freeman Fang:
> Sure, please fill a jira, and patch is always welcomed!
> －－－－－－－－－－－－－
> Freeman(Yue) Fang
>
> Red Hat, Inc. 
> FuseSource is now part of Red Hat
>
>
>
> On 2014-2-4, at 下午8:36, Andreas Mattes wrote:
>
>> Hi,
>>
>> In a customer project, we have the following issue:
>>
>> There are services with non-standard WSDL definitions, 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.
>>
>> As we assume that there may be more cases with similar situations, and with explicit setting of the WSDL_OPERATION, the expected behaviour is that this hint is not overridden unless it is really inconsistent, we would file a Jira issue with a proposed fix.
>>
>> Kind regards,
>>
>> Andreas Mattes
>>
>> Talend Germany
>>
>

Re: Handling of WSDL_OPERATION property in CXF impl of JAX-WS Dispatch

[Freeman Fang <fr...@gmail.com>]

Sure, please fill a jira, and patch is always welcomed!
－－－－－－－－－－－－－
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat



On 2014-2-4, at 下午8:36, Andreas Mattes wrote:

> Hi,
> 
> In a customer project, we have the following issue:
> 
> There are services with non-standard WSDL definitions, 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.
> 
> As we assume that there may be more cases with similar situations, and with explicit setting of the WSDL_OPERATION, the expected behaviour is that this hint is not overridden unless it is really inconsistent, we would file a Jira issue with a proposed fix.
> 
> Kind regards,
> 
> Andreas Mattes
> 
> Talend Germany
>