axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hudson (JIRA)" <>
Subject [jira] [Commented] (AXIS-928) Input parameter resolution by QName always fails in 1.1 final
Date Sat, 29 Sep 2012 12:10:07 GMT


Hudson commented on AXIS-928:

Integrated in axis-trunk #155 (See [])
    Migrated test/wsdl/rpcParams (AXIS-928) to the Maven build. Also refactored the test case
to use the Call API instead of a manually modified stub. (Revision 1391782)

     Result = SUCCESS
veithen : 
Files : 
* /axis/axis1/java/trunk/integration/pom.xml
* /axis/axis1/java/trunk/integration/src/test/java/test/wsdl/rpcParams
* /axis/axis1/java/trunk/integration/src/test/java/test/wsdl/rpcParams/
* /axis/axis1/java/trunk/integration/src/test/java/test/wsdl/rpcParams/
* /axis/axis1/java/trunk/integration/src/test/wsdd/wsdl/rpcParams
* /axis/axis1/java/trunk/integration/src/test/wsdd/wsdl/rpcParams/deploy.wsdd
* /axis/axis1/java/trunk/integration/src/test/wsdl/rpcParams
* /axis/axis1/java/trunk/integration/src/test/wsdl/rpcParams/rpcParams.wsdl
* /axis/axis1/java/trunk/test/wsdl/rpcParams

> Input parameter resolution by QName always fails in 1.1 final
> -------------------------------------------------------------
>                 Key: AXIS-928
>                 URL:
>             Project: Axis
>          Issue Type: Bug
>          Components: Serialization/Deserialization
>    Affects Versions: 1.1
>         Environment: Operating System: All
> Platform: All
>            Reporter: dave_marquard
>         Attachments: ASF.LICENSE.NOT.GRANTED--diff.txt, ASF.LICENSE.NOT.GRANTED--patch.txt,
> 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
> 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.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message