DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16339>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16339 Axis WSDL Support Issue: WSDL SOAP Binding vs. SOAP RPC Summary: Axis WSDL Support Issue: WSDL SOAP Binding vs. SOAP RPC Product: Axis Version: 1.1beta Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: Other Component: Serialization/Deserialization AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Currently, when initializing an org.apache.axis.client.Service object using a WSDL document, the method return part in the WSDL message definition MUST be named exactly the same as the element in the returned SOAP Envelope that contains the return value or else Axis will throw an error while parsing the return (because Axis serialization uses the WSDL part definition to figure out which QName to look for).... the error is thrown because Axis cannot find the element containing the return value. While this is sufficient to satisify the WSDL specification constraint expressed in Section 3.5: "Each message part (parameter) appears under the wrapper, represented by an accessor named identically to the corresponding parameter of the call. Parts are arranged in the same order as the parameters of the call", it does cause somewhat of a conflict with the SOAP specification RPC binding which states in Section 7.1 "The name of the return value accessor is not significant". The behavior of the deserialization process should be changed to the following: 1. First, attempt to find the return element using the WSDL message part definition. 2. If the return element cannot be found (e.g. when the name of the return element in the SOAP message does not equal the name of the return part in the WSDL message definition), then use the first child element as the return element. Doing so will satisify both the WSDL and SOAP spec constraints.
