[
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2317?page=c...
]
Martin Kneissl commented on HHH-2317:
-------------------------------------
We seem to have this issue, too, with Hibernate 3.2.6. The hibernate-3.1.patch solves the
problem for us.
Specific details:
- We have the Hibernate 3.2.6 jars in the JBoss/server/xxx/lib directory. Let's call
the class loader handling this directory "J" (for JBoss).
- We have an enterprise app to deploy as EAR with separate class loader. The hibernate
session factory for this application is configured using an MBean from a SAR within the
EAR. Let's call the application class loader "A" (for application).
Problem: Hibernate is not able to load the CGLIB generated proxy class. Our analysis shows
that the CGLIB generated byte code that references the application class interfaces cannot
be loaded. This is because hibernate does not tell CGLIB which class loader to use and
CGLIB implicitly takes the one from the first interface of the generated proxy. This often
is a hibernate provided interface (HibernateProxy), coming from class loader
"J". This class loader has no access to the classes from class loader
"A", where the application interfaces come from, so CGLIB cannot load the proxy
class.
The following alternatives have been evaluated and rejected:
- Putting hibernate into the EAR and removing it from JBoss/server/xxx/lib. This prevents
using EJB3 because the EJB3 deployer uses class loader "J" and has dependencies
on hibernate that would now reside in class loader "A".
- Not using a separate class loader for the EAR. This prevents redeployment since the
classes used from the hibernate mapping would remain in the one and only relevant class
loader "J" when the EAR is undeployed.
The patch provided by Pietu above (hibernate-3.1.patch) solves the problem, we would be
glad to see it in a future hibernate release.
I still have the feeling that the ClassLoader for the generated proxy classes should be
defined explicitly by hibernate.
Ideas:
a) Perhaps the class loader should be defined via the SessionFactory as a strategy and
then used by the CGLIBLazyInitializer to define the class loader in CGLIB's Enhancer.
b) Or, a little less general and less invasive, use the class loader of the
persistentClass aka entityClass of the proxy to be created. I consider it more likely that
the entity class comes from the application class loader than that all of the interfaces
come from the application class loader.
A patch for 3.2.6 to implement b) will follow, soon.
CGLIB unable to lazy load classes in diff. classloader than
hibernate jars
---------------------------------------------------------------------------
Key: HHH-2317
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2317
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.2.1
Reporter: Jason Novotny
Attachments: hibernate-3.1.patch
Please see
http://forum.hibernate.org/viewtopic.php?p=2334617#2334617 for more details
and possible fix
--
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