I have never seen this specific error message before but I can explain a bit about what it means and give one possible cause.
The line
java.lang.NoClassDefFoundError: Could not initialize class org.hibernate.ejb.Ejb3Configuration
doesn't mean that the JVM could not find the class org.hibernate.ejb.Ejb3Configuration
. It means that the JVM can find this class but it has already tried and failed to load this class.
It's the text Could not initialize class ...
that indicates that this has happened. If the JVM couldn't find the class at all you'd get something like the following instead:
java.lang.NoClassDefFoundError: org/hibernate/ejb/Ejb3Configuration
As an aside, it also means you're using Java 6 - in Java 5 the corresponding exception has no message.
The following two classes provide a demonstration of this behaviour. The class Unloadable
cannot be loaded because its static initializer always throws an exception. We attempt to load this class, catch the ExceptionInInitializerError
that results, and attempt to load Unloadable
again.
class Unloadable {
static {
if (true) { throw new RuntimeException(); }
}
}
public class LoadingTest {
public static void main(String[] args) throws Exception {
try {
Class.forName("Unloadable");
}
catch (ExceptionInInitializerError e) {
try {
Class.forName("Unloadable");
}
catch (NoClassDefFoundError e2) {
System.out.println("XXXXXXXXXXXXXXXXXXXXX");
e2.printStackTrace(System.out);
}
}
}
}
When I run class LoadingTest
, I get the following output:
XXXXXXXXXXXXXXXXXXXXX
java.lang.NoClassDefFoundError: Could not initialize class Unloadable
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at LoadingTest.main(LoadingTest.java:14)
I cannot say what is causing the original attempt to load org.hibernate.ejb.Ejb3Configuration
to fail. It could well be that Ejb3Configuration
itself depends on classes that are missing from the classpath. It might be worth going through the list of all the classes import
ed by Ejb3Configuration and ensuring that all those not under java.*
or javax.*
are within a JAR that Glassfish and Netbeans can see.
Also, I can only speculate as to why the JVM is attempting to load Ejb3Configuration
twice. When the class loading fails for the first time, an exception (typically some subclass of LinkageError
) is thrown. This type of exception isn't often caught, so my best guess is that something like the following is happening:
try {
// Some code that loads Ejb3Configuration and fails.
}
finally {
// Some code that also loads Ejb3Configuration and fails.
}
If the code in the finally
block throws an exception, this exception will replace any exception thrown in the try
block. I suggest this because a similar thing happened on this question. The stack trace posted in this question comes from within a finally
block.
If my answer still doesn't help you, could you please post the entire stack trace you're seeing?