Description
This is related to https://jira.jboss.org/jira/browse/JBWS-2528
java2wsdl does not generate the parameterOrder attribute in the wsdl portType/operation element. This is required to preserve the original method signature of a webmethod in cases where soapHeader and IN/OUT parameters are used at the same time.
For instance for a method like this:
@WebMethod
public String hello3(@WebParam(name = "id", targetNamespace = "hello3/Name", header = true) String name,
@WebParam(name = "Name", mode = WebParam.Mode.OUT) Holder<Name> name2,
@WebParam(name = "Employee", mode = WebParam.Mode.INOUT) Holder<Employee> employee)
throws NameException
we get this portType:
<wsdl:portType name="JBWS2528Endpoint">
<wsdl:operation name="hello3">
<wsdl:input name="hello3" message="tns:hello3">
</wsdl:input>
<wsdl:output name="hello3Response" message="tns:hello3Response">
</wsdl:output>
<wsdl:fault name="NameException" message="tns:NameException">
</wsdl:fault>
</wsdl:operation>
</wsdl:portType>
instead of
<wsdl:portType name="JBWS2528Endpoint">
<wsdl:operation name="hello3" parameterOrder="id Name Employee">
<wsdl:input name="hello3" message="tns:hello3">
</wsdl:input>
<wsdl:output name="hello3Response" message="tns:hello3Response">
</wsdl:output>
<wsdl:fault name="NameException" message="tns:NameException">
</wsdl:fault>
</wsdl:operation>
</wsdl:portType>
This is relevant when doing java -> wsdl -> java (using CXF tools) and expecting the generated endpoint interface to be the same as the initial one. This issue was revealed when running the JavaEE 5 CTS TCK using JBossWS-CXF and configuring the jws/webparam3 reverse test. Without the parameterOrder attribute, a different interface is generated and the client test does not compile because of that.