Я до сих пор не видел этого сообщения об ошибке, но могу немного пояснить, что это значит и дать одну возможную причину.
Линия
java.lang.NoClassDefFoundError: Could not initialize class org.hibernate.ejb.Ejb3Configuration
не означает, что виртуальная машина не может найти класс org.hibernate.ejb.Ejb3Configuration
. Это означает, что JVM может найти этот класс, но он уже попробовал и не смог загрузить этот класс.
Это текст Could not initialize class ...
, который указывает, что это произошло. Если виртуальная машина не может найти класс на все, что вы хотите получить что-то вроде следующего вместо:
java.lang.NoClassDefFoundError: org/hibernate/ejb/Ejb3Configuration
Как и в сторону, это также означает, что вы не используете Java 6 - в Java 5 соответствующее исключение не имеет сообщение.
Следующие два класса демонстрируют это поведение. Класс Unloadable
не может быть загружен, потому что его статический инициализатор всегда выдает исключение. Мы пытаемся загрузить этот класс, поймаем результат ExceptionInInitializerError
и попытаемся снова загрузить Unloadable
.
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);
}
}
}
}
Когда я бегу класс LoadingTest
, я получаю следующий результат:
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)
Я не могу сказать, что вызывает оригинальную попытку загрузки org.hibernate.ejb.Ejb3Configuration
на провал. Вполне возможно, что сам Ejb3Configuration
зависит от классов, отсутствующих в пути к классам. Возможно, стоит перечислить список всех классов import
ed от Ejb3Configuration и убедиться, что все те, которые не находятся под java.*
или javax.*
, находятся в JAR, которые могут видеть Glassfish и Netbeans.
Кроме того, я могу только догадываться, почему JVM пытается загрузить Ejb3Configuration
дважды. Когда сбой загрузки классов в первый раз, исключение (обычно некоторый подкласс LinkageError
). Этот тип исключения не часто поймали, так что моя догадка, что-то вроде следующего происходит:
try {
// Some code that loads Ejb3Configuration and fails.
}
finally {
// Some code that also loads Ejb3Configuration and fails.
}
Если код в блоке finally
генерирует исключение, это исключение заменит любое исключение, брошенный в try
блок. Я предлагаю это, потому что подобное произошло на this question. Трассировка стека, отправленная в этом вопросе, поступает из блока finally
.
Если мой ответ по-прежнему не поможет вам, не могли бы вы разместить всю трассировку стека, которую видите?
Похоже, что это действительно в конфигурации Log4J, которая не упоминается в трассировке стека, за исключением случаев, когда сервер сначала перезапускается. –