-
1. Re: Exception on hot re-deploy of EAR using JBossCache
starksm64 Jan 10, 2005 11:20 PM (in response to tcherel)This is due to destroyed class loaders being used. The redeployment destroys the previous class loader and nulls its associated repository. Any danging references to the old class loader wil result in an NPE.
-
2. Re: Exception on hot re-deploy of EAR using JBossCache
tcherel Jan 11, 2005 3:48 AM (in response to tcherel)Thanks for the answer.
Is there something that I am doing wrong in my package to cause this issue?
This is happening upon the re-deploy of the EAR, so I am wondering why the re-deploy is using a destroyed class loader instead of a "new one".
Any suggestions on how I might fix it or is the JBoss restart the only way to go?
Thanks.
Thomas -
3. Exception on hot re-deploy of EAR using JBossCache (JBoss 4.
dbjav Jan 20, 2005 11:21 AM (in response to tcherel)I got the exact same problem with JBoss 4.0.1 JDK 1.4.2_06.
Is it because my application code does some:this.getClass().getClassLoader()
Anything we can do to avoid having to restart JBoss ?
The problem also appears only after redeployment.
Denis -
4. Re: Exception on hot re-deploy of EAR using JBossCache
tcherel Jan 20, 2005 11:29 AM (in response to tcherel)I did not find a way to fix it.
May be with class loader scoped ear, but I am not sure (I did not try).
Thomas -
5. Re: Exception on hot re-deploy of EAR using JBossCache
dbjav Jan 21, 2005 5:01 AM (in response to tcherel)Hi Thomas,
Have a look at this thread:
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=58900
To solve our problem, I just removed the driver jars from my .ear and put them instead in JBoss lib under the default server. I did not get the exception on redeploy since then.
Cheers.
Denis -
6. Re: Exception on hot re-deploy of EAR using JBossCache
tcherel Jan 21, 2005 5:12 AM (in response to tcherel)Thanks for the pointer.
In my case, I do not have any JDBC driver jar in my ear.
But I suppose that putting the JBossCache jars (the error is occuring on a JBossCache class) in the server/lib instead of the EAR will solve the problem.
I do not like the idea too much as I'd like to have my EAR as portable as possible from one app server to another, avoiding any global classpath changes, if possible.
Thomas