> 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. --Glen
