[Hibernate-JIRA] Created: (HHH-3870) Hibernate proxies Groovy's getMetaClass method breaking proxies when used with Groovy
1:18 p.m.
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.3.1, 3.3.0.SP1, 3.3.0.GA, 3.3.0.CR2, 3.3.0.CR1, 3.2.6
Reporter: Graeme Rocher
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:33 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3870) Hibernate proxies Groovy's getMetaClass method breaking proxies when used with Groovy
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3870?page=c...
]
Emmanuel Bernard commented on HHH-3870:
---------------------------------------
A a = session.load(A, 1L) if 1L is of a C instance is wrong in the first place. Users
should use from A where id = :id
Any other use case where that causes problem?
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
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:39 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3870) Hibernate proxies Groovy's getMetaClass method breaking proxies when used with Groovy
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3870?page=c...
]
Graeme Rocher commented on HHH-3870:
------------------------------------
Ok bad example. A more appropriate example is when you have a lazy loaded association.
There is an example attached to this JIRA http://jira.codehaus.org/browse/GROOVY-3433
Basically download the script and the ivysettings.xml file and then just run:
{code}
groovy TestScript.groovy
{code}
You will need Groovy 1.6.0 (not 1.6.1, the change to "fix" this in 1.6.1 was
inappropriate and will be rolled back in 1.6.2, see the JIRA for details)
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
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:13 p.m.
New subject: [Hibernate-JIRA] Assigned: (HHH-3870) Hibernate proxies Groovy's getMetaClass method breaking proxies when used with Groovy
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3870?page=c...
]
Emmanuel Bernard reassigned HHH-3870:
-------------------------------------
Assignee: Emmanuel Bernard
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:13 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3870) Hibernate proxies Groovy's getMetaClass method breaking proxies when used with Groovy
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3870?page=c...
]
Emmanuel Bernard commented on HHH-3870:
---------------------------------------
I told you guys a long time ago that using a getter convention would be problematic :)
I'm also wondering if you could mark the method as bridge or synthetic to that people
can easily filter it out.
What i don't fully understand is that accessing a property of a subclass is pretty bad
in the first place. You sure you want to allow that? That could break at any moment
depending on the "subclass".
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
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:15 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3870) Hibernate proxies Groovy's getMetaClass method breaking proxies when used with Groovy
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3870?page=c...
]
Emmanuel Bernard commented on HHH-3870:
---------------------------------------
also bypassing the proxy means that you are facing the risk of accessing uninitialized
field in what ever you do with the meta class.
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:29 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3870) Hibernate proxies Groovy's getMetaClass method breaking proxies when used with Groovy
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3870?page=c...
]
Graeme Rocher commented on HHH-3870:
------------------------------------
It is unfortunately not changeable now. Feel free to provide suggestions on the Groovy
JIRA on how it can be solved. For sure accessing a property of a subclass is bad, however
you have to understand Groovy is dynamic :-)
In Java you would get a classcast exception, however because of Groovy's dynamic
dispatch it allows you to invoke methods dynamically using duck typing to the underlying
proxied instance. However this is falling over because the getMetaClass method is being
proxied itself which confuses Groovy and makes it get the wrong meta class causing the
IllegalArgumentException.
Anyway slight change to the proposed fix:
{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}
But as I said ideally the proxying mechanism of Hibernate should a) work out of the box
with Groovy and b) be more configurable for other cases where this must be an issue
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:25 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3870) Hibernate proxies Groovy's getMetaClass method breaking proxies when used with Groovy
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3870?page=c...
]
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:25 a.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3870) Hibernate proxies Groovy's getMetaClass method breaking proxies when used with Groovy
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3870?page=c...
]
Graeme Rocher commented on HHH-3870:
------------------------------------
- would there be a way for Groovy to get the metaclass of A (would it even make sense)?
Yes if the getMetaClass() call wasn't being proxied this is what would happen
- you agree that metaClass must *not* access lazy objects if we bypass the proxy call
Agreed, it won't anyway, it works purely at the class level.
- 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?
I guess you would have to check the return type which is a groovy.lang.MetaClass
- I'm almost certain we should still trigger initialize() when getMetaClass is called
I don't agree, I have a local custom implementation of EntityPersister that excludes
the getMetaClass method from being proxied which gives me the correct behavior for Grails
right now.
- 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.
Ok let me try to illustrate an example. Say you lookup a proxied instance of A:
A a = .. // lookup A
The underlying instance is actually as instance of C. However, the proxy instance
'a' is not an instance of C because Hibernate has dynamically subclassed A. Now
you try to invoke a method on 'a':
a.foo()
This results in the pseudo code:
a.getMetaClass().invokeMethod(a, "foo")
However, since the getMetaClass() method is proxied instead of returning the MetaClass for
A it proxies to the underlying instance something like:
a.getHibernateLazyInitializer().getImplementation().getMetaClass().invokeMethod(a,
"foo")
Now the problem is a.getHibernateLazyInitializer().getImplementation().getMetaClass()
returns the MetaClass for 'C', but the proxy instance 'a' is not an
instance of 'C', instead it is a dynamically subclassed instance of A. The result
is that the call to invokeMethod(a, "foo") eventually delegates to something
like:
java.lang.reflect.Method fooMethod = .. // lookup foo method
fooMethod.invoke(a, null)
However because the instance 'a' is not an instance of 'C' this blows up
with a ClassCastException which is re-thrown inside java.lang.reflect.Method.invoke(..) as
a IllegalArgumentException. Now in Java you would get something similar because in Java
say you loaded 'A':
A a = .. // lookup A
And then tried to do:
((C)a).foo()
You would get a ClassCastException because 'a' is not a 'C', however the
reason is more clear whilst with Groovy you get this weird IllegalArgumentException which
is is hard to debug and is caused by the proxying of the getMetaClass() method. You should
actually be getting a MissingMethodException and in fact in Grails with my custom
EntityPersister that is what you get. Well actually this is not quite true because we have
added this bit of code to Grails:
public static void enhanceProxy ( HibernateProxy proxy ) {
proxy.metaClass.propertyMissing = { String name, val ->
if(delegate instanceof HibernateProxy) {
def obj = GrailsHibernateUtil.unwrapProxy(delegate)
if(val != null) {
obj?."$name" = value
}
return obj."$name"
}
else {
throw new MissingPropertyException(name, delegate.class)
}
}
proxy.metaClass.methodMissing = { String name, args ->
if(delegate instanceof HibernateProxy) {
def obj = GrailsHibernateUtil.unwrapProxy(delegate)
return obj."$name"(*args)
}
else {
throw new MissingPropertyException(name, delegate.class)
}
}
}
Which will automatically delegate to the proxied instance when you experience any
MissingMethodExceptions etc. That actually makes the experience with Hibernate proxies in
Grails better than what you get with Java :-)
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:11 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3870) Hibernate proxies Groovy's getMetaClass method breaking proxies when used with Groovy
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3870?page=c...
]
Emmanuel Bernard commented on HHH-3870:
---------------------------------------
One last question (hopefully).
Assuming the unproxying of metaclass.
class A {
String getName() { return name; }
}
class C extends A {
String getFoo() {
return "foo " + name;
}
}
now someone does in Groovy
a.getFoo();
with the metaclass thingy, we call c.getFoo() which calls c.getName().
Now name is not loaded yet (lazy) => we are in trouble because we have bypassed the
proxy. Right?
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:19 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3870) Hibernate proxies Groovy's getMetaClass method breaking proxies when used with Groovy
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3870?page=c...
]
Emmanuel Bernard commented on HHH-3870:
---------------------------------------
Otherwise I am planning
return !( m.getParameterTypes().length == 0 &&
( m.getName().equals( "finalize" ) ||
//Groovy
(m.getName().equals( "getMetaClass" )
&& m.getReturnType().getName().equals( "groovy.lang.MetaClass" )
)
) );
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:24 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3870) Hibernate proxies Groovy's getMetaClass method breaking proxies when used with Groovy
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3870?page=c...
]
Graeme Rocher commented on HHH-3870:
------------------------------------
On your example, I am not sure. It may be an issue, probably worth writing a test for.
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:22 p.m.
New subject: [Hibernate-JIRA] Commented: (HHH-3870) Hibernate proxies Groovy's getMetaClass method breaking proxies when used with Groovy
[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-3870?page=c...
]
Jochen Theodorou commented on HHH-3870:
---------------------------------------
as for the synthetic flag... getMetaClass is a synthetic method if added by the compiler
automatically.
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:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5488
days inactive
5489
days old
hibernate-issues@lists.jboss.org
12 comments
3 participants
participants (3)
-
Emmanuel Bernard (JIRA) -
Graeme Rocher (JIRA)
-
Jochen Theodorou (JIRA)