Input parameter bug in 1.1 final

[David Marquard <Da...@forgent.com>]

I recently filed a report
(http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20930) about a serious
input parameter bug in 1.1 final, and I'm hoping I can drum up some
discussion here on the list about a solution.

The bug is that for RPC/Encoded web services, the ParameterDesc objects
generated incorrectly list parameter QNames as
"{operationNamespace}attributeName" instead of simply "attributeName" as is
indicated in the WSDL. As a result, the RPCHandler is unable to match
parameters in client requests with the corresponding ParameterDesc objects
using the QName. When the name lookup fails, RPCHandler falls back to using
the order parameters appear in the request to lookup the corresponding
ParameterDesc objects.

This works fine unless the client request omits any of the parameters, in
which case the position lookup strategy fails. For example, if the operation
description includes parameters { in0 in1 in2 } but the request sent only
includes { in1 in2 } (since in0 is null), the position lookup indicates that
the request parameter in1 matches up with the ParameterDesc object for in0.
This eventually leads to SAXExceptions and other bad stuff.

Anyway, this bug was introduced in the ServiceDesc class in the patch for
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19274 (a Document/Literal
WSDL generation problem). One solution to the current problem is simply to
roll back that patch, but that of course breaks 19274. Unfortunately, I
don't have any experience with Document/Literal stuff, so I don't even
understand the problem that the 19274 patch was trying to solve.

So I have two questions for you guys:

1) Does anyone know of a solution to both problems that's not just rolling
back the changes introduced in 19274?

2) Does anyone else think that this bug warrants a 1.1.1 release? I've
patched 1.1 on my end, but imagine a decent number of other users might run
into this one...

Dave

_________________________________________
Dave Marquard (dave_marquard@forgent.com)