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.
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?
I got the exact same problem with JBoss 4.0.1 JDK 1.4.2_06.
Is it because my application code does some:
Anything we can do to avoid having to restart JBoss ?
The problem also appears only after redeployment.
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).
Have a look at this thread:
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.
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.