Причина: java.lang.NoClassDefFoundError: org/apache/log4j/Logger

Question

У меня есть интересная проблема, в которой класс org.apache.log4j.Logger не найден во время выполнения. Я пытаюсь получить разрешение, и вот где это не удается:

OAuthAuthorizer oauthAuthorizer = new OAuthAuthorizer(OAUTH_CONSUMER_KEY, OAUTH_CONSUMER_SECRET, SAML_PROVIDER_ID, userId);

Я использую JDeveloper 11.1.1.6. Вот что я знаю:

1. Я заглянул в свой каталог UI.war/WEB-INF/lib и увидел там log4j-1.2.17.jar.

2. Класс, жалующийся на это - org.opensaml.xml.XMLConfigurator

   Caused by: java.lang.NoClassDefFoundError: org/apache/log4j/Logger
       at org.opensaml.xml.XMLConfigurator.<clinit>(XMLConfigurator.java:60)
       at org.opensaml.DefaultBootstrap.initializeXMLTooling(DefaultBootstrap.java:195)
       at org.opensaml.DefaultBootstrap.bootstrap(DefaultBootstrap.java:91)
       at com.intuit.ipp.aggcat.util.SAML2AssertionGenerator.getSAMLBuilder(SAML2AssertionGenerator.java:156)
       at com.intuit.ipp.aggcat.util.SAML2AssertionGenerator.createSubject(SAML2AssertionGenerator.java:187)
       at com.intuit.ipp.aggcat.util.SAML2AssertionGenerator.buildAssertion(SAML2AssertionGenerator.java:114)
       at com.intuit.ipp.aggcat.util.SAML2AssertionGenerator.generateSignedAssertion(SAML2AssertionGenerator.java:83)
       at com.intuit.ipp.aggcat.util.SamlUtil.createSignedSAMLPayload(SamlUtil.java:156)
       at com.intuit.ipp.aggcat.util.OAuthUtil.getOAuthTokens(OAuthUtil.java:60)
       at com.intuit.ipp.aggcat.core.OAuthAuthorizer.<init>(OAuthAuthorizer.java:85)
       at com.incomemax.view.intuit.WebUtil.getAggCatService(WebUtil.java:91)
   

   Caused by: java.lang.ClassNotFoundException: org.apache.log4j.Logger
       at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
       at java.security.AccessController.doPrivileged(Native Method)
       at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:305)
       at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
       at java.lang.ClassLoader.loadClass(ClassLoader.java:246)
       ... 64 more
   

3. Я декомпилировал XMLConfigurator и, как ни странно, он не импортирует org.apache.log4j.Logger. Он использует org.slf4j.Logger, который также находится в моей директории jars (slf4j-api-1.7.5.jar). Также интересно, что строка 60 (смотрите трассировку стека) - это пустая строка в моем декомпиляции.

4. Конечно, если я добавлю Logger.xxxxx во время разработки, он будет в порядке.

5. Я использую код / ​​jars непосредственно из примера кода Java, но импортируется в мое существующее приложение.

Я искал в Интернете ответы и считаю, что проверил все области, о которых могу подумать. Я также ссылался на эту очень хорошую страницу: http://myarch.com/classnotfound/

Учитывая, что авторизация является первым шагом в использовании Intuit Developer API, я немного застрял.

Добавление вывода из предложения @jhadesdev:

Все версии log4j Logger:

• ZIP:C:/Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/log4j-1.2.17.jar!/org/apache/log4j/Logger.class

Все версии log4j видимы из загрузчика классов класса OAuthAuthorizer:

• ZIP:C:/Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/log4j-1.2.17.jar!/org/apache/log4j/Logger.class

Все версии XMLConfigurator:

• баночка: Файл:/C:/Oracle/Middleware11116/modules/com.bea.core.bea.opensaml2_1.0.0.0_6-1-0-0.jar /org/opensaml/xml/XMLConfigurator.class

• ZIP:C:/Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/ipp-java-aggcat-v1-DevKit-1.0.2.jar!/org/opensaml/xml/XMLConfigurator.class

• ZIP:C:/Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/xmltooling-1.3.1.jar!/org/opensaml/xml/XMLConfigurator.class

Все версии XMLConfigurator видимы из загрузчика классов класса OAuthAuthorizer:

• баночка: Файл:/C:/Oracle/Middleware11116/modules/com.bea.core.bea.opensaml2_1.0.0.0_6-1-0-0.jar /org/opensaml/xml/XMLConfigurator.class

• ZIP:C:/Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/ipp-java-aggcat-v1-DevKit-1.0.2.jar!/org/opensaml/xml/XMLConfigurator.class

• ZIP:C:/Users/Chris/AppData/Roaming/JDeveloper/system11.1.1.6.38.61.92/DefaultDomain/servers/DefaultServer/tmp/_WL_user/j2ee-app/lt5l71/war/WEB-INF/lib/xmltooling-1.3.1.jar!/org/opensaml/xml/XMLConfigurator.class

Я все еще работаю над интерпретацией результатов.

Answer 1

С предложениями @jhadesdev и объяснениями других я нашел проблему здесь.

После добавления кода, чтобы увидеть то, что было видно различным загрузчикам классов, я нашел это:

All versions of log4j Logger: 
  zip:<snip>war/WEB-INF/lib/log4j-1.2.17.jar!/org/apache/log4j/Logger.class

All versions of log4j visible from the classloader of the OAuthAuthorizer class: 
  zip:<snip>war/WEB-INF/lib/log4j-1.2.17.jar!/org/apache/log4j/Logger.class

All versions of XMLConfigurator: 
  jar:<snip>com.bea.core.bea.opensaml2_1.0.0.0_6-1-0-0.jar!/org/opensaml/xml/XMLConfigurator.class
  zip:<snip>war/WEB-INF/lib/ipp-java-aggcat-v1-devkit-1.0.2.jar!/org/opensaml/xml/XMLConfigurator.class
  zip:<snip>war/WEB-INF/lib/xmltooling-1.3.1.jar!/org/opensaml/xml/XMLConfigurator.class

All versions of XMLConfigurator visible from the classloader of the OAuthAuthorizer class: 
  jar:<snip>com.bea.core.bea.opensaml2_1.0.0.0_6-1-0-0.jar!/org/opensaml/xml/XMLConfigurator.class
  zip:<snip>war/WEB-INF/lib/ipp-java-aggcat-v1-devkit-1.0.2.jar!/org/opensaml/xml/XMLConfigurator.class
  zip:<snip>war/WEB-INF/lib/xmltooling-1.3.1.jar!/org/opensaml/xml/XMLConfigurator.class

Я заметил, что может быть поднята другая версия XMLConfigurator. Я декомпилировал этот класс и нашел его в строке 60 (где ошибка была в исходной трассировке стека) private static final Logger log = Logger.getLogger(XMLConfigurator.class); и этот класс импортировал из org.apache.log4j.Logger!

Так что именно этот класс загружался и использовался. Мое исправление состояло в том, чтобы переименовать файл jar, который содержал этот файл, поскольку я не могу найти, где я явно или косвенно загружаю это. Что может создать проблему, когда я действительно развернусь.

Спасибо за помощь и столь необходимый урок по загрузке классов.

Answer 2

Во время выполнения ваше приложение не может найти банку.

Взято из этого ответа Jared:

В этом случае важно держать в уме два разных исключения:

1. java.lang.ClassNotFoundException Это Exception, это означает, что класс не был найден на пути к классам. Это указывает на то, что мы пытались загрузить определение класса, а класс не существовал в пути к классам.

2. java.lang.NoClassDefFoundError Это Error, это указывает на то, что JVM искала в своей внутренней структуре данных определения класса определение класса и не нашла его. Это отличается от того, что он не может быть загружен из пути к классам. Обычно это означает, что мы ранее пытались загрузить класс из пути к классам, но по какой-то причине это не удалось - теперь мы пытаемся снова, но даже не собираемся пытаться загрузить его, потому что мы не смогли загрузить его ранее. Более ранний сбой мог быть ClassNotFoundException или ExceptionInInitializerError (указывающий на сбой в блоке статической инициализации) или любым другим количеством проблем. Дело в том, что NoClassDefFoundError не обязательно является проблемой пути к классам.

за сходства и различия

Answer 3

Вы можете использовать следующую зависимость maven в вашем файле pom. В противном случае вы можете скачать следующие две jar-файлы из сети и добавить их в путь сборки.

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.6.4</version>
</dependency>

<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-log4j12</artifactId>
    <version>1.6.4</version>
</dependency>

Это скопировано из моего рабочего проекта. Сначала убедитесь, что он работает в вашем проекте. Затем вы можете изменить версии, чтобы использовать любые другие (версии) совместимые банки.

Для AggCat вы можете ссылаться на POM-файл примера Java-приложения.

https://github.com/IntuitDeveloperRelations/IPP_Sample_Code/blob/master/CustomerAccountData/Java/AggCatSampleApplication/pom.xml

Спасибо

Answer 4

Проверьте в сборке развертывания,

У меня та же ошибка, когда я генерирую файл war способом "maven clean install" и внедряю вручную, он работает нормально, но когда я использую среду выполнения (eclipse), возникают проблемы.

Решение для меня (для eclipse IDE): "Свойства проекта" -> "Сборка развертывания" -> "Добавить" -> "Необходимая фляга", в моем случае java "записи пути сборки". Может быть, может помочь немного!

Answer 5

Основанный на трассировке стека, интуитивный класс com.intuit.ipp.aggcat.util.SAML2AssertionGenerator нуждается в saml jar на пути к классам.

Класс saml org.opensaml.xml.XMLConfigurator в свою очередь нуждается в log4j, который находится внутри WAR, но не может его найти.

Одним из объяснений этого является то, что класс XMLConfigurator, которому требуется log4j, был найден не внутри WAR, а в нижележащем загрузчике классов. Может ли банка Самл отсутствовать в ВОЙНЕ?

Класс XMLConfigurator, которому требуется log4j, не может найти его на уровне загрузчика классов, который его загрузил, и версия log4j в WAR не видна в этом конкретном загрузчике классов.

Чтобы устранить это, можно добавить это до вызова oauth:

System.out.println("all versions of log4j Logger: " + getClass().getClassLoader().getResources("org/apache/log4j/Logger.class") );

System.out.println("all versions of XMLConfigurator: " + getClass().getClassLoader().getResources("org/opensaml/xml/XMLConfigurator.class") );

System.out.println("all versions of XMLConfigurator visible from the classloader of the OAuthAuthorizer class: " + OAuthAuthorizer.class.getClassLoader().getResources("org/opensaml/xml/XMLConfigurator.class") );

System.out.println("all versions of log4j visible from the classloader of the OAuthAuthorizer class: " + OAuthAuthorizer.class.getClassloader().getResources("org/apache/log4j/Logger.class") );

Также, если вы используете Java 7, взгляните на jHades, это инструмент, который я сделал, чтобы помочь в устранении подобных проблем.

Чтобы увидеть, что происходит, не могли бы вы опубликовать результаты запросов classpath выше, для какого контейнера это происходит, tomcat, jetty? На всякий случай было бы лучше поместить полную трассировку стека со всеми причинами, вызванными в pastebin.

Answer 6

Была та же самая проблема, это было действительно вызвано тем, что weblogic тупо использовал свою собственную реализацию opensaml. Чтобы решить это, вы должны сказать ему, чтобы загрузить классы из WEB-INF/lib для этого пакета в weblogic.xml:

    <prefer-application-packages>
        <package-name>org.opensaml.*</package-name>
    </prefer-application-packages>

может быть <prefer-web-inf-classes>true</prefer-web-inf-classes> будет работать тоже.

Answer 7

java.lang.ClassNotFoundException указывает, что класс не найден в пути к классам. это может быть версия log4j не совместима. проверьте другую версию log4j.

Answer 8

Добавьте compile 'org.apache.logging.log4j:log4j-1.2-api:2.17.1', и тогда он будет работать автоматически

Answer 9

У меня была та же проблема, для меня это исправило проблему:
щелкните правой кнопкой мыши по проекту ->maven -> обновить проект

обновить проект>

Answer 10

В моем случае ошибка возникла из-за некоторых зависимостей с использованием log4j v 1.x, которые я удалил из пути к классам. Поэтому я представил log4j-1.2-apiсоединить v 1.x с 2.x, как рекомендовано в руководстве по миграции Apache :

После введения этой зависимости в мой build.gradle, ошибка исчезла:

implementation 'org.apache.logging.log4j:log4j-1.2-api:2.17.+!!'

Answer 11

Следующие работы для меня каждый раз, когда я сталкиваюсь с проблемой

щелкните правой кнопкой мыши проект (скажем, abc-war) -> свойства -> сборка развертывания -> добавить -> записи пути сборки Java -> зависимости Maven.