Yes, it is a bug - a bug in the spec supplied javax.persistence.Persistence.class. There is a work around available for you. Instead of packaging Hibernate classes in the ear file, please put them in GlassFish/lib directory and restart the server. That will fix the issue. Now read on, what is the bug... The spec supplied javax.persistence.Persistence.class (https://glassfish.dev.java.net/source/browse/glassfish/persistence-api/sr...) has a static variable defined like this: protected static final Set<PersistenceProvider> providers = new HashSet<PersistenceProvider>(); | In createEntityManagerFactory() method, it uses currentThread.getContextClassLoaded() to search for all the persistence providers and stores them in that variable. Obviously, this is an optimization attempt, but it is not free from trouble. One of the scenarios where it does not always work is in your case, where the providers are bundled in the application ear/jar/war. First time, you deploy the app, providers variable is populated with HibernatePersistence.class loaded by the application class-loader that the app was associated with at that point of time. When you redeploy, the app is now associated with a new class loader, and we expect the old class loader to be garbage collected. But, because of this providers variable, the old HibernatePersistence.class is used. GlassFish is written to protect against it, so we detect the situation and disallow the class loading. Hence you see that exception. I have been able to fix this issue by patching Persistence.class. I will file an issue in GlassFish and see how we can address the spec supplied class. In the mean while, you should be able to use the work around suggested earlier. Thanks, Sahoo View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4056607#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...