[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2317?page=c... ] Max Rydahl Andersen commented on HHH-2317: ------------------------------------------ what exactly does not work here ? testcase? I load classes constantly from a different classloader; namely the one that is set via the current context thread classloader. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2317?page=c... ] Max Rydahl Andersen commented on HHH-2317: ------------------------------------------ And why is it not enough for you to set the current thread context classloader before and after the calls ? But in any case having both hibernate in server lib and your web app sounds like a *really* bad idea. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2317?page=c... ] Max Rydahl Andersen commented on HHH-2317: ------------------------------------------ so remove the hibernate jars you have in webapp's and just use the one in the server lib. But only load classes when you actually are inside the scope of the webapp! Nothing weird about this. But it is definitly not recommended to use libs from server libs since it very often (always?) result in redeployment being a pain since you can't unload those classes. -- 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

[ 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. -- 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