- priority: 5 --> 9
- assigned_to: nobody --> gregerohlson
I'm debugging the XmlServer/XmlClient/*Employee*
example, which is giving me the following error:
8/4/03 3:04 PM XmlRpcServerConnection-0 Error:
java.lang.IllegalArgumentException: argument type
mismatch at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke
(Method.java:324)
at
marquee.xmlrpc.handlers.ReflectiveInvocationHandler.exe
cute(ReflectiveInvocationHandler.java:217)
at
marquee.xmlrpc.handlers.ReflectiveInvocationHandler.invo
ke(ReflectiveInvocationHandler.java:149)
at marquee.xmlrpc.XmlRpcDispatcher.dispatch
(XmlRpcDispatcher.java:152)
at marquee.xmlrpc.XmlRpcServerConnection.run
(XmlRpcServerConnection.java:223)
Apparently the CallWrapper that is built on the client by
Proxy.invoke() is not being "unwrapped" in
ReflectiveInvocationHandler.
Line 209 of ReflectiveInvocationHandler v1.5 has:
if ( !parameterTypes[
j ].isAssignableFrom( argClasses[ j ] ) )
{
break;
}
I noticed this has changed in v1.6 to (along with other
updates):
if ( !parameterTypes[
j ].isAssignableFrom( argClasses[ j ] ) )
{
continue outer;
}
The v1.5 version is thus calling method.invoke on line
217 even if the arguments are not assignment
compatible with the parameters, which is the case here
because the arguments are wrapped in a CallWrapper
object. Thus the IllegalArgumentException. I noticed
somebody added a patch in the Bugs section to fix the
last problem, but that still leaves the CallWrapper
problem unresolved.
Shawn Keller reported a problem in objectcomm on 12
April 2002, at which point passing objects from server to
client was working for him. Did some of the later CVS
commits break objectcomm functionality?