[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2317) CGLIB unable to lazy load classes in diff. classloader than hibernate jars

[Martin Kneissl (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33007#action_33007 ] 

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.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira