[ http://issues.apache.org/jira/browse/AXIS-1675?page=comments#action_12315755 ]
sebastien tardif commented on AXIS-1675: ---------------------------------------- JAXRPC 1.1 doesn't care much about how the generated signature show up when two returns value exist. ALL the test case that everybody are using to test between each others just test with one return parameter. All unit test of Axis are passing after this patch is applied. All JAXRPC 1.1 say is this: Ordering of Java parameters is represented in the parameterOrder attribute in the wsdl:operation element. The message part for a return value is not listed in the parameterOrder attribute. Refer to the WSDL 1.1 specification for more details on the parameterOrder attribute. But parameterOrder doesn't applied with wrapped doc/literal. Wrapped doc/literal is what .NET support. In other words: JAXRPC 1.1 had half thought this issue, leaving a lot to interpretation. There is no workaround to this problem. This is the best solution I can find which is also compatible with the next specification. We can presume that the authors of JAXRPC 2.0 tried also to minimize the backward compatibility problem when they choose this approach. This is working with .NET, and the best solution found that is the most compatible with WebLogic, WebSphere, WebMethod and JWSDP. I can understand you are worry about backward compatibility of codegen. So let me present you the worst case: To break an existing interface, the interface will need to: - Have more than one return value - One of the parameter will have to be "return" (case sensitive) The author then will have to be upset that the parameter "return" become the return value... > WSDL2Java doesnt use return value when two out parameters exist. > ----------------------------------------------------------------- > > Key: AXIS-1675 > URL: http://issues.apache.org/jira/browse/AXIS-1675 > Project: Apache Axis > Type: Bug > Components: Serialization/Deserialization > Versions: 1.2RC2 > Environment: cvs 11/19/2004 > Reporter: Sébastien Tardif > Assignee: Davanum Srinivas > Attachments: diff.txt, docHarbor.wsdl > > Title: WSDL2Java doesnt use return value when two out parameters exist. > From my WSDL I get this: > void getDocument(Credential credential, Users users, DocumentRequest > documentRequest, DocumentResponseHolder _return, ByteArrayHolder document) > throws RemoteException; > void getDocumentAsAttachment(Credential credential, Users users, > DocumentRequest documentRequest, OctetStreamHolder document, > holders.DocumentResponseHolder _return) throws RemoteException; > As you can see operation [getDocument] has two out parameters: [document] and > [return]. > Operation [getDocumentAsAttachment] has also two out parameters: [document] > and [return]. > The result should be: > DocumentResponse getDocument(Credential credential, Users users, > DocumentRequest documentRequest, ByteArrayHolder document) throws > RemoteException; > > DocumentResponse getDocumentAsAttachment(Credential credential, Users users, > DocumentRequest documentRequest, OctetStreamHolder document) throws > RemoteException; > The code in Axis try sometime to take one of the out parameters and take it > as the return type but in my case it doesnt trigger. > To have a long time fix I suggest to just implement right now the JAX-RPC 2.0 > way which is to map to the return value of the signature the element using > name: [return] as shown below: > From section 2.3.2 Parameter Order and Return Type of JAX-RPC 2.0 > specification: > Wrapper style mapping If there is a single out wrapper child then it forms > the method return type, > if there is an out wrapper child with a local name of return then it forms > the method return > type, otherwise the return type is void. > From section 3.8.2 Method and Parameters of JAX-RPC 2.0 specification: > <xsd:element name="getPriceResponse" type="tns:getPriceResponseType"/> > <xsd:complexType name="getPriceResponseType"> > <xsd:sequence> > <xsd:element name="return" type="xsd:float"/> > </xsd:sequence> > </xsd:complexType> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
