Re: JDK Style Proxy Issue

Mark Menard schrieb:
[...]
> the issue still remains with JDK style
> dynamic proxies manufactured by java.lang.reflect.Proxy.newProxyInstance().
>
> So, I guess my question would be is it the intent of the Groovy developers
> to support the JDK method of doing a dynamic proxy of a Groovy object?

of course ;)

> I'm
> willing to work on the issue. I have a lot of code predicated on this
> methodology using Groovy 1.0, so I definitely have an "itch" so to speak.

As far as I can tell it is a bug in Groovy's MetaClass. It is relevant
if the call is made from a proxied object or not, it is relevant if the
call is made from Groovy or at last in the Groovy way. Because then the
call goes through MetaClassImpl and the bug is caused.

First let me try to explain something about MetaClassImpl. When a method
is onvoked the call goes through a MetaClass in Groovy. But if this is
done by Reflection which Class would you take the method from?
ServiceBeanImpl1 implements GroovyObject and ServiceBean, which means
the method doService exists two times, one time from the interface
ServiceBean and one time from the class ServiceBeanImpl1. Because of
several problems related to classloaders we started to oprefer the
interface method over the class method. When called it is the same, but
if you need to cast it is not. The proxy problem now is not related to
classloaders, but the cast problem persists in a different form. If you
invoke doService on a Proxy backed by ServiceBeanImpl1 then MetaClass
will choose the proxy as object to make the invocation on, but selects
doService from ServiceBeanImpl1. The result is that the invocation will
fail, because the proxy is no ServiceBeanImpl1.

Bug 1:
The obvious bug is that MetaClassImpl chooses doService from the
implementing class instead of the interface. Normally there is code
preventing this in isValidReflectorMethod, but the code there is called
from createMetaMethod and calls the same method again causing problems
with the field interfaceMethods.

Bug 2:
After correcting this I see that that the information from before is
lost in later steps.. I guess using the methods from the
interfaceMethods field directly would help. But this would means to not
to get a valid value for MetaMethod#getDeclaringClass, which is needed
at different locations. So this fix can't be done this way. Maybe a new
MetaMethod type should be used?

bye blackdrag

--
Jochen "blackdrag" Theodorou
Groovy Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email