Our project setup:
- Glassfish 3.0.1
- Hibernate 3.5.3 bundled in the WAR
- Eclipse 3.5.2 with Glassfish plug-in
[b]The problem:[/b]
Editing and saving a file in Eclipse causes the WAR to be redeployed to the running Glassfish instance. After 5 or 6 edit-redeploy cycles, Glassfish throws OutOfMemory exceptions, usually you have to kill Glassfish and restart Eclipse to continue working.
I first wrote about the problem here
http://forums.java.net/jive/message.jspa?messageID=475587
and filed a bug report
https://glassfish.dev.java.net/issues/show_bug.cgi?id=12368.
The same effect occurs when redeploying the WAR outside of Eclipse using asadmin redeploy, so Eclipse is not a contributing factor.
[b]The workaround:[/b]
Run Hibernate using cglib as bytecode provider instead of the default javassist. To do so, set the system property
-Dhibernate.bytecode.provider=cglib
in your domain.xml. Setting this property in persistence.xml has no effect.
[b]The root cause:[/b]
There is an incorrect usage of a WeakHashMap in javassist which is bundled deep down in Glassfish within Weld, holding strong references to old WebappClassLoaders. For some reason, weld-osgi-bundle.jar exports the package javaassist.util.proxy in its OSGi manifest and does not keep its copy of javassist fully private. This is bound to cause problems is OSGi land: either you keep a dependency fully private, or you import it from another bundle. Partially exporting it creates a problem for any other bundle requiring the same dependency.
Our WAR includes hibernate.jar and javassist.jar, but due to parent classloader delegation, Hibernate ends up with the javassist.util.proxy.ProxyFactory exported by Weld, leaving all the dangling webapp classloader references in the container.
[Message sent by forum member 'hwellmann']
http://forums.java.net/jive/thread.jspa?messageID=478506