DO NOT REPLY [Bug 20930] New: - Input parameter resolution by QName always fails in 1.1 final

[bu...@apache.org]

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: axis-dev@ws.apache.org
        ReportedBy: dave_marquard@forgent.com


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.