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 >
