As the stack shows, GlassFish is trying to clean up by closing EMFs at
undeploy. By this time, the WebappClassLoader is already disposed. It is
strange for an app to initiate a new class load while being cleaned up
like done here by EhCacheRegionFactory. That said, this use case should
not be precluded. Please file a bug against jpa-connector or deployement
component of GlassFish to get this resolved.
Thanks,
Mitesh
On 5/23/2011 12:14 PM, forums_at_java.net wrote:
> Hi,
>
> I've been running into an issue where an exception is thrown when
> undeploying
> an application on Glassfish 3.1 (b43). The stack trace looks like this:
>
> java.lang.IllegalStateException: WEB9031: WebappClassLoader unable to
> load
> resource [net.sf.ehcache.transaction.xa.processor.XARequestProcessor],
> because it has not yet been started, or was already stopped at
> org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1410)
>
> at
> org.glassfish.web.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1368)
>
> at net.sf.ehcache.CacheManager.shutdown(CacheManager.java:1174) at
> net.sf.ehcache.hibernate.EhCacheRegionFactory.stop(EhCacheRegionFactory.java:101)
>
> at
> org.hibernate.impl.SessionFactoryImpl.close(SessionFactoryImpl.java:958)
> at
> org.hibernate.ejb.EntityManagerFactoryImpl.close(EntityManagerFactoryImpl.java:127)
>
> at
> org.glassfish.persistence.jpa.JPADeployer.closeEMFs(JPADeployer.java:404)
> at
> org.glassfish.persistence.jpa.JPADeployer.event(JPADeployer.java:395) at
> org.glassfish.kernel.event.EventsImpl$1.run(EventsImpl.java:120) at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at
>
> java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at
> java.util.concurrent.FutureTask.run(FutureTask.java:138) at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>
> at java.lang.Thread.run(Thread.java:662)
> Using the -XX:+TraceClassLoading flag shows that the
> XARequestProcessor class
> isn't loaded prior to being referenced from CacheManager#shutdown,
> meaning
> that the shutdown method is making a request for the class to be loaded.
> However, the WebappClassLoader instance is already stopped when that
> request
> is made, leading to this exception. It just so happens that this also
> prevents the WebappClassLoader instance from being garbage collected,
> which
> causes all the libraries in the web application to remain in memory
> indefinitely.
>
> I've attached a simple test case that I've been using to reproduce this
> exception - simply deploying and undeploying the application gives the
> exception (note that you will need to add a JVM flag to get around the
> NPE
> obscuring the actual exception:
> -Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=false).
>
> I've also tried deploying/undeploying on Glassfish 3.0.1 - no
> exception is
> thrown there.
>
> Does anyone have any experience with this? It looks like the lifecycle
> of the
> class loader isn't properly coordinated with the lifecycle of the JPA
> subsystem. Any ideas?
>
> Thanks in advance.
>
>
> --
>
> [Message sent by forum member 'atomicknight']
>
> View Post: http://forums.java.net/node/805307
>
>
>