Verursacht durch: java.lang.NoClassDefFoundError: org/apache/log4j/Logger

Lesezeit: 11 Minuten

Benutzer-Avatar
Liebesbier84

Ich habe ein interessantes Problem, bei dem die Klasse org.apache.log4j.Logger während der Laufzeit nicht gefunden wird. Ich versuche, autorisiert zu werden, und hier scheitert es:

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

Ich verwende JDeveloper 11.1.1.6. Folgendes weiß ich:

  1. Ich habe in meinem Verzeichnis UI.war/WEB-INF/lib nachgesehen und sehe dort die Datei log4j-1.2.17.jar.

  2. Die Klasse, die sich darüber beschwert, ist 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. Ich habe XMLConfigurator dekompiliert und seltsamerweise importiert es org.apache.log4j.Logger nicht. Es verwendet org.slf4j.Logger, das sich auch in meinem Jars-Verzeichnis befindet (slf4j-api-1.7.5.jar). Interessant ist auch, dass Zeile 60 (siehe Stack-Trace) eine Leerzeile in meiner Dekompilierung ist.

  4. Natürlich, wenn ich Logger.xxxxx während der Entwurfszeit hinzufüge, findet es es ganz gut.

  5. Ich verwende den Code/die Gläser direkt aus dem Beispiel-Java-Code, aber in meine vorhandene Anwendung importiert.

Ich habe das Internet nach Antworten durchsucht und ich glaube, ich habe alle Bereiche überprüft, die mir einfallen. Ich habe auch auf diese sehr gute Seite verwiesen: http://myarch.com/classnotfound/

Die gegebene Autorisierung ist Schritt 1 bei der Verwendung der Intuit Developer API, ich stecke irgendwie fest.

Ausgabe von @jhadesdev-Vorschlag hinzufügen:

Alle Versionen von 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

Alle Versionen von log4j, die im Classloader der Klasse OAuthAuthorizer sichtbar sind:

  • 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

Alle Versionen von XMLConfigurator:

  • jar:file:/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

Alle Versionen von XMLConfigurator, die vom Klassenlader der Klasse OAuthAuthorizer sichtbar sind:

  • jar:file:/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

An der Interpretation der Ergebnisse arbeite ich noch.

  • Wenn Sie Tomcat 8 verwenden und einen der Ordner in Ihrer Web-App symbolisch verlinkt haben, benötigen Sie eine allowLinking Attribut: <Context><Resources allowLinking="true"/> in $CATALINA_HOME/conf/context.xml

    – GlenPeterson

    12. November 2014 um 23:18 Uhr

Benutzer-Avatar
Premraj

Während der Laufzeit kann Ihre Anwendung das JAR nicht finden.

Aus dieser Antwort von Jared entnommen:

In diesem Fall ist es wichtig, zwei verschiedene Ausnahmen im Kopf zu behalten:

  1. java.lang.ClassNotFoundException Dies ein Exception, gibt es an, dass die Klasse nicht im Klassenpfad gefunden wurde. Dies weist darauf hin, dass wir versucht haben, die Klassendefinition zu laden, und die Klasse nicht im Klassenpfad vorhanden war.

  2. java.lang.NoClassDefFoundError Das ist Error, gibt es an, dass die JVM in ihrer internen Klassendefinitionsdatenstruktur nach der Definition einer Klasse gesucht und sie nicht gefunden hat. Dies ist anders als zu sagen, dass es nicht aus dem Klassenpfad geladen werden konnte. Normalerweise weist dies darauf hin, dass wir zuvor versucht haben, eine Klasse aus dem Klassenpfad zu laden, aber aus irgendeinem Grund fehlgeschlagen ist – jetzt versuchen wir es erneut, aber wir werden nicht einmal versuchen, sie zu laden, weil wir sie zuvor nicht geladen haben. Der frühere Fehler könnte eine ClassNotFoundException oder ein ExceptionInInitializerError (was auf einen Fehler im statischen Initialisierungsblock hinweist) oder eine beliebige Anzahl anderer Probleme sein. Der Punkt ist, dass ein NoClassDefFoundError nicht unbedingt ein Klassenpfadproblem ist.

für Gemeinsamkeiten und Unterschiede

  • Tolle Erklärung @premraj. Basierend darauf habe ich hinzugefügt LOG.error("Just entered getAggCatService"); am Anfang meines Codes und stellte sicher, dass mein Import org.apache.log4j.Logger war. Meine Protokollnachricht wurde angezeigt. Würde das nicht bedeuten, dass org.apache.log4j.Logger geladen und dann gefunden wurde?

    – lovebeer84

    3. Januar 2014 um 19:46 Uhr

  • Das passiert, wenn man extrem faul wird und auf zweideutige Klassennamen kommt. Gute Arbeit Java-Person.

    – Boss

    28. Juli um 14:59 Uhr

Benutzer-Avatar
Manas Mukherjee

Sie können die folgende Maven-Abhängigkeit in Ihrer Pom-Datei verwenden. Andernfalls können Sie die folgenden beiden JAR-Dateien aus dem Netz herunterladen und Ihrem Erstellungspfad hinzufügen. 

<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>

Dies ist aus meinem Arbeitsprojekt kopiert. Stellen Sie zunächst sicher, dass es in Ihrem Projekt funktioniert. Dann können Sie die Versionen ändern, um andere (Versionen) kompatible JAR-Dateien zu verwenden.

Für AggCat können Sie auf die POM-Datei der Java-Beispielanwendung verweisen.

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

Vielen Dank

  • Mein Build funktionierte in Eclipse, schlug aber über die Befehlszeile auf dem MAC fehl. Das Problem war, dass mir das zweite Artefakt dieser Lösung fehlte. slf4j-log4j12. Ich denke, Eclipse hat es standardmäßig enthalten.

    – Sacky San

    24. Juli 2017 um 1:08 Uhr

  • Das Hinzufügen von lof4j-over-slf4j löst dieses Problem. slf4j-log4j12 gibt Fehler beim Hinzufügen für log4j-Abhängigkeiten org.slf4j log4j-over-slf4j ${slf4j-api.version}

    – Shubham Pandey

    8. Mai 2018 um 11:13 Uhr

  • Ich bekam diesen Fehler von spring-kafka-test und sein zookeeper Abhängigkeit. Hinzufügen slf4j-log4j12 als testbezogene Abhängigkeit hat das Problem für mich behoben.

    – Jack Stroh

    7. September 2018 um 0:56 Uhr

  • Lief wie am Schnürchen. Ich habe mit Big Queue gearbeitet github.com/bulldog2011/bigqueue und dieser Fehler ist aufgetreten. Hoffe, das würde jemandem helfen

    – ahroran

    25. November 2020 um 7:02 Uhr

Benutzer-Avatar
perezmirabile

Bereitstellungsmontage einchecken,

Ich habe den gleichen Fehler, wenn ich die War-Datei mit dem “Maven Clean Install”-Weg generiere und manuell ausführe, funktioniert es gut, aber wenn ich die Laufzeitumgebung (Eclipse) verwende, treten die Probleme auf.

Die Lösung für mich (für die Eclipse-IDE) lautet: “Proyect Properties” –> “Deployment Assembly” –> “Add” –> “the jar you need”, in meinem Fall Java “Build Path Entries”. Kann vielleicht ein bisschen helfen!

Mit den Vorschlägen von @jhadesdev und den Erklärungen von anderen habe ich das Problem hier gefunden.

Nachdem ich den Code hinzugefügt hatte, um zu sehen, was für die verschiedenen Klassenlader sichtbar war, fand ich Folgendes:

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

Mir ist aufgefallen, dass möglicherweise eine andere Version von XMLConfigurator abgeholt wird. Ich habe diese Klasse dekompiliert und diese in Zeile 60 gefunden (wo der Fehler im ursprünglichen Stack-Trace lag) private static final Logger log = Logger.getLogger(XMLConfigurator.class); und aus dieser Klasse wurde importiert org.apache.log4j.Logger!

Es war also diese Klasse, die geladen und verwendet wurde. Meine Lösung bestand darin, die JAR-Datei umzubenennen, die diese Datei enthielt, da ich nicht finden kann, wo ich sie explizit oder indirekt lade. Was ein Problem darstellen kann, wenn ich es tatsächlich einsetze.

Danke für alle Hilfe und die dringend benötigte Lektion zum Laden von Klassen.

Benutzer-Avatar
Winkeluniversität

Basierend auf dem Stacktrace benötigt eine Intuit-Klasse com.intuit.ipp.aggcat.util.SAML2AssertionGenerator ein SAML-JAR im Klassenpfad.

Eine Saml-Klasse org.opensaml.xml.XMLConfigurator benötigt wiederum log4j, das sich im WAR befindet, es aber nicht finden kann.

Eine Erklärung dafür ist, dass die Klasse XMLConfigurator, die log4j benötigt, nicht im WAR, sondern in einem nachgeschalteten Classloader gefunden wurde. Könnte ein Saml-Glas im WAR fehlen?

Der Klassen-XMLConfigurator, der log4j benötigt, kann es auf der Ebene des Classloaders, der es geladen hat, nicht finden, und die log4j-Version in der WAR-Datei ist auf diesem bestimmten Classloader nicht sichtbar.

Um dies zu beheben, können Sie dies vor dem oauth-Aufruf hinzufügen:

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") );

Auch wenn Sie Java 7 verwenden, werfen Sie einen Blick auf jHadeses ist ein Tool, das ich entwickelt habe, um bei der Behebung dieser Art von Problemen zu helfen.

Um zu sehen, was los ist, könnten Sie die Ergebnisse der Klassenpfadabfragen oben posten, für welchen Container passiert das, Tomcat, Jetty? Es wäre besser, den vollständigen Stacktrace mit allen verursachten Bys in Pastebin abzulegen, nur für den Fall.

  • Ich habe deinen vorgeschlagenen Code hinzugefügt. Ich muss nur herausfinden, wie ich es einfügen kann, da es für ein Kommentarfeld in Stackoverflow zu lang ist.

    – lovebeer84

    3. Januar 2014 um 20:10 Uhr

  • Vergessen hinzuzufügen … Ich verwende den Weblogic-Server 11g, das wäre also der Derby-Server

    – lovebeer84

    3. Januar 2014 um 20:19 Uhr

Benutzer-Avatar
Denis Tulsky

Hatte das gleiche Problem, es wurde tatsächlich von Weblogic verursacht, das dummerweise seine eigene Opensaml-Implementierung verwendet. Um es zu lösen, müssen Sie ihm sagen, dass es Klassen laden soll WEB-INF/lib für dieses Paket in weblogic.xml:

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

kann sein <prefer-web-inf-classes>true</prefer-web-inf-classes> würde auch funktionieren.

  • Ich habe deinen vorgeschlagenen Code hinzugefügt. Ich muss nur herausfinden, wie ich es einfügen kann, da es für ein Kommentarfeld in Stackoverflow zu lang ist.

    – lovebeer84

    3. Januar 2014 um 20:10 Uhr

  • Vergessen hinzuzufügen … Ich verwende den Weblogic-Server 11g, das wäre also der Derby-Server

    – lovebeer84

    3. Januar 2014 um 20:19 Uhr

Benutzer-Avatar
Dharmraj

java.lang.ClassNotFoundException zeigt an, dass die Klasse nicht im Klassenpfad gefunden wird. Es könnte sein, dass die Version von log4j nicht kompatibel ist. Suchen Sie nach einer anderen log4j-Version.

  • wie finde ich heraus ob es kompatibel ist?

    – John Ktejik

    17. Dezember 2021 um 16:46 Uhr

1109030cookie-checkVerursacht durch: java.lang.NoClassDefFoundError: org/apache/log4j/Logger

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy

Contact - Terms and Conditions - Privacy Policy