]
Emmanuel Bernard commented on HHH-3870:
---------------------------------------
On b. we have plans to make that more configurable but it's not trivial and will
likely require Hibernate 4.
Few more question before choosing one patch over an other:
- would there be a way for Groovy to get the metaclass of A (would it even make sense)?
- you agree that metaClass must *not* access lazy objects if we bypass the proxy call
- is there a way to know that getMetaClass is the Groovy's metaclass and not some
random metaClass property? looking for the groovy Object class? What's the fqcn
again?
It seems the proposed solution (a) is not the correct one:
- I'm almost certain we should still trigger initialize() when getMetaClass is
called
- I don't fully understand why you end up with the IllegalArgumentException. Maybe
the proxy should still intercept but do something different for getMetaClass. not sure
what yet.
Hibernate proxies Groovy's getMetaClass method breaking proxies
when used with Groovy
-------------------------------------------------------------------------------------
Key: HHH-3870
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3870
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.2.6, 3.3.0.CR1, 3.3.0.CR2, 3.3.0.GA, 3.3.0.SP1, 3.3.1
Reporter: Graeme Rocher
Assignee: Emmanuel Bernard
Priority: Critical
Say you have a class hierarchy like A->B-C and you obtain a proxied instance of C
{code}
A a = session.load(A, 1L)
{code}
When Groovy invokes a method it looks up the objects metaclass by calling the
getMetaClass() method on A. The pseudo code for Groovy method dispatch is something like:
{code}
a.getMetaClass().invokeMethod(a, "foo")
{code}
The problem is that the getMetaClass() method is being proxied onto the underlying
instance of C so when a.getMetaClass() is called you get the MetaClass for the class C,
but because of the way Hibernate creates proxies it is not an instance of C at all, but
instead an dynamically created subclass of A. The result is you get an
IllegalArgumentException that is hard to debug.
In Grails we have worked around this by customizing Hibernate's proxy creation
mechanism to not proxy the getMetaClass() method. The problem this mechanism is currently
insanely difficult to customize and also usage of Groovy on its own outside of Grails is
still broken with Hibernate (such as inside JBoss Seam)
It would be great if one of two things could be done:
a) Hibernate does not proxy the getMetaClass() method at all this could be done by
modifying JavassistLazyInitializer and the associated cglib one as follows:
{code}
private static final MethodFilter FINALIZE_FILTER = new MethodFilter() {
public boolean isHandled(Method m) {
// skip finalize methods
return !( m.getParameterTypes().length == 0 && (m.getName().equals(
"finalize" ) || m.getName().equals( "getMetaClass" ) ));
}
};
{code}
b) The mechanism for creating proxies is made easier to customize so that the
getMetaClass() method can be easily excluded via some configuration or something. However,
this would still mean that out of the box Hibernate is broken when used with Groovy unless
the solution a) is applied too
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: