[
https://issues.apache.org/jira/browse/CXF-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12523169
]
maomaode commented on CXF-939:
------------------------------
After i fixed this issue, and suddenly find that we already check this, you
have to turn on the -validate during wsdl2java
Actually we have two checking points, one to check the wsdlDefinition (in case
of wsdl11), and another is to check the serviceModel(cxf internal wsdl model)
the uniqueBodyPartValidator is at the first checking point, so if you turn on
the -validate, you will see the error message similar to the one you gave
And my fix is at the second checking point, so kind of double check now
And I'm thinking of turn of the second checking point by default, so even if
you don't specify the -validate, the serviceModel will be checked by default
> wsdl defining two different operations on the same port using the same
> messages lead to wsdl2java producing wrong code instead of an error message
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: CXF-939
> URL: https://issues.apache.org/jira/browse/CXF-939
> Project: CXF
> Issue Type: Bug
> Components: Tooling
> Affects Versions: 2.0
> Reporter: Christian Pfeifhofer
> Assignee: maomaode
> Attachments: bug.wsdl
>
>
> A WSDL defining two operations on the same port with different names but
> using the same message names for request and response lead to wrong code
> instead of an error message. wsdl2java produces a port interface class with
> both operations, but with wrong runtime behavior. The request of a client
> invoking the second operation will be routed to the implementation of the
> first operation at the service provider site.
> This is the code generated:
> @WebService(targetNamespace = "http://bugs.cxf/services/bug1";, name =
> "myBug1Port")
> public interface MyBug1Port {
> @SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE)
> @WebResult(targetNamespace = "http://bugs.cxf/services/bug1";, partName =
> "parameters", name = "myBug1Response")
> @WebMethod
> public cxf.bugs.services.bug1.ResponseDataType myBug2(
> @WebParam(targetNamespace = "http://bugs.cxf/services/bug1";, partName
> = "parameters", name = "myBug1")
> cxf.bugs.services.bug1.RequestDataType parameters
> );
> @ResponseWrapper(targetNamespace = "http://bugs.cxf/services/bug1";,
> className = "cxf.bugs.services.bug1.ResponseDataType", localName =
> "myBug1Response")
> @RequestWrapper(targetNamespace = "http://bugs.cxf/services/bug1";,
> className = "cxf.bugs.services.bug1.RequestDataType", localName = "myBug1")
> @WebResult(targetNamespace = "http://bugs.cxf/services/bug1";, name =
> "myOutputString")
> @WebMethod
> public java.lang.String myBug1(
> @WebParam(targetNamespace = "http://bugs.cxf/services/bug1";, name =
> "myInputString")
> java.lang.String myInputString
> );
> }
> The jaxws ri produces an error message instead, as two operations with equal
> message names are illegal at the same port:
> Non unique body parts! In a port, operations must have unique operation
> signaure on the wire for successful dispatch. In port myBug1, Operations
> "myBug2" and "myBug1" have the same request body block
> {http://bugs.cxf/services/bug1}myBug1
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
