axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Daniels <>
Subject RE: Clash test
Date Wed, 20 Feb 2002 13:47:18 GMT

> I'm still not sure I understand the problem with the clash test.  The
> testcase is calling "void sharedName(int)".  That method DOES 
> exist on all
> the generated files:  the interface, the skeleton, the impl.  It is
> overloaded:  "void sharedName(int)", "int sharedName()", "void
> sharedName(boolean)".  "<sharedName>0</sharedName>" shouldn't 
> be ambiguous
> (or is 0 a legal boolean value?).  What exactly is the error 
> you're seeing?

The problem is that the determineDefaultParams() code, which is what figures out the types
from introspecting the java.lang.Method, does not currently deal with method overloading -
it used to randomly pick the first method with the right # of arguments, I think, but it doesn't
now.  So when we try to deserialize the <sharedName>, we end up resorting to the "use
the element QName as the type name and see if that works" hack, which finds a valid type (SharedNameType),
so we end up with one of those, which does NOT match either of the one-arg method signatures.

Fixing the introspection logic to handle overloads will deal with this to some extent, though
there are certainly a lot of cases which will still be random (method(int) vs. method(String)
for instance) without some other differentiator.


View raw message