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=20930>. 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=20930 Input parameter resolution by QName always fails in 1.1 final Summary: Input parameter resolution by QName always fails in 1.1 final Product: Axis Version: 1.1 Platform: All OS/Version: All Status: NEW Severity: Blocker Priority: Other Component: Serialization/Deserialization AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have encountered a bug in Axis 1.1 where Axis is never able to resolve request parameters by QName using OperationDesc.getInputParamByQName(). According to the description object, the parameters are named "{operation-namespace}parameter-name". When the request (correctly) refers to the parameters using only "parameter-name", getInputParamByQName() fails. The net result is that if a request has ommitted parameters, everything blows up. After RPCHandler is unable to look up a parameter description by QName, it falls back to looking up the parameter by its position in the request. If a parameter has been ommitted, this lookup returns the incorrect description since there are fewer parameters in the request than in the operation description. For example, if an operation description includes paramters { in0 in1 in2 } and a request comes including only { in1 in2 }, this lookup associates in1 in the request with in0 in the operation description. The cause of this regression appears to be the patch to ServiceDesc that was introduced with the fix for http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19274. I have attached a patch against 1.1 that rolls back that change. I realize that this will break what that patch was trying to fix in the first place; unfortunately, I don't know enough about Java2WSDL and/or Document/Literal encoding to suggest an alternate patch.
