axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject Clash test
Date Tue, 19 Feb 2002 23:16:25 GMT

Hi guys:

I'm in the midst of revamping some stuff, during which I did some surgery on the way RPCProvider
dispatches to target methods.  In particular, I added a clause to save some time which ignores
overloaded methods with FEWER parameters than those we have from the XML deserialization.
 This lit up a serious bug that had been present in the code - namely the fact that if there
were no arguments in a given method, that one would get called regardless of the argument
list we were currently working with from the XML.  In other words if you had:

 public int method() { return 5; }
 public void method(int value) { // do something }

And received XML with a single int param, it's just as likely you'd dispatch to the first
method as the second.

Turns out this bug, which has been sitting there a while, it seems, is the reason that the
wsdl "clash" test was working.  Once it was fixed, the problems with the clash test became

In particular, test #5 in the SharedName_ServiceTestCase calls what it thinks is the method
that looks like "void sharedName(int)".  It sends XML that contains a parameter that has no
xsi:type on it (since it's literal), with an element name of <sharedName>, i.e. <sharedName>0</sharedName>.
 So the runtime gets this, and since there are multiple "sharedName" methods, it can't figure
out the types from introspection via determineDefaultParams() (in org.apache.axis.message.RPCHandler).
 So it looks for a type attribute - no luck.  Then it says "hey, does the element QName happen
to match a type I know about?" and lo and behold it does - only this isn't an int, it's a
"SharedNameType".  So we merrily attempt to deserialize one of those, even though the XML
isn't quite right for that (NOTE: we should probably be able to enforce throwing faults for
missing bean elements).  OK, so now we have our SharedNameType in hand, and get to RPCProvider
to figure out what method to call.  Well, because of the earlier bug I mentioned, we find
the method that looks like "int sharedName()", and since it has no params we just call it
and happily return.

That's what WAS happening.  Now the test breaks in my sandbox because we're NOT calling the
wrong backend method.

So how do we deal with this?  It's a little hard to pinpoint the exact problem(s), so let's
tease it apart:

1) When lacking an xsi:type attribute, we don't know how to deserialize a given piece of XML
if there are multiple potential types.  Right now there's an assumption that deserialization
is done when we get to the RPCProvider, and we just try JavaUtils.convert() to coerce whatever
we have into whatever we might want.  I think the right solution to this might be to keep
track of the fact that there are overloaded methods during deserialization.  Pick a random
method to use as "starter" metadata, and if one of the deserializations fails, we should back
up, click the method counter forward, and try deserializing the XML again as the next type.

2) We should remove the "use the element QName as the type" code, I think it might be bogus
except for particular elements like <SOAP-ENC:int>.  It's not a generally good thing.

3) We need to be able to differentiate between overloaded methods where you can't dispatch
based on the XML (i.e. "void method(int)" and "void method(String)" where there's a single
<arg>5</arg>).  Most other toolkits seem to do this with SOAPAction, which we
could do also.  We could also have a SOAP header based solution.

4) The clash test should be given a thorough once-over.  .NET's wsdl tool chokes on it, and
I'm not convinced it's really good WSDL testing what we want to test.

I have to go for the evening, but I'll take a look at this again tomorrow.  Russell, if you
can spare some time I would really appreciate some help going over the test to figure out
what its doing right and wrong, because I'd like to check my changes in at some point during
the day tomorrow.

Comments/opinions welcome.


View raw message