wake-up-neo.com

Auslöser: Java.lang.NoClassDefFoundError: org/Apache/log4j/Logger

Ich habe ein interessantes Problem, bei dem die org.Apache.log4j.Logger-Klasse zur Laufzeit nicht gefunden wird. Ich versuche, autorisiert zu werden und das ist, wo es fehlschlägt:

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

Ich benutze JDeveloper 11.1.1.6. Folgendes weiß ich:

  1. Ich habe in meinem UI.war/WEB-INF/lib-Verzeichnis 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 den XMLConfigurator dekompliert und merkwürdigerweise importiert er org.Apache.log4j.Logger nicht. Er 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 meinem Dekompilat ist.

  4. Wenn ich Logger.xxxxx während der Entwurfszeit hinzufüge, ist das natürlich in Ordnung.

  5. Ich verwende den Code/die JAR-Dateien direkt aus dem Java-Beispielcode, importiere sie jedoch in meine vorhandene Anwendung.

Ich habe im Internet nach Antworten gesucht und glaube, ich habe alle Bereiche überprüft, die mir in den Sinn kommen. Ich habe auch auf diese sehr gute Seite verwiesen: http://myarch.com/classnotfound/

Die Autorisierung ist Schritt 1 bei der Verwendung der Intuit Developer API.

Hinzufügen der Ausgabe von @jhadesdev Vorschlag:

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 vom Klassenladeprogramm der OAuthAuthorizer-Klasse sichtbaren Versionen von log4j:

  • 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 Klassenladeprogramm der OAuthAuthorizer-Klasse angezeigt werden:

  • 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

Ich arbeite immer noch an der Interpretation der Ergebnisse.

35
lovebeer84

Mit den Vorschlägen @jhadesdev und den Erklärungen anderer 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

Ich bemerkte, dass möglicherweise eine andere Version von XMLConfigurator aufgegriffen wurde . Ich dekompilierte diese Klasse und fand diese in Zeile 60 (wo der Fehler im ursprünglichen Stack-Trace war) private static final Logger log = Logger.getLogger(XMLConfigurator.class); und diese Klasse importierte 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 bei der Bereitstellung ein Problem darstellen kann.

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

3
lovebeer84

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

Entnommen aus dieser Antwort von Jared :

Es ist wichtig, zwei unterschiedliche Ausnahmen in unserem Kopf aufrechtzuerhalten. in diesem Fall:

  1. Java.lang.ClassNotFoundException Dies ist eine Exception, die angibt, dass Klasse wurde nicht im Klassenpfad gefunden. Dies zeigt an, dass wir .__ waren. beim Versuch, die Klassendefinition zu laden, und die Klasse war nicht auf .__ vorhanden. der Klassenpfad.

  2. Java.lang.NoClassDefFoundError Dies ist Error, es gibt an, dass die JVM suchte in seiner internen Klassendefinitionsdatenstruktur nach der Definition einer Klasse und fand sie nicht. Dies ist anders als sagen, dass es nicht aus dem Klassenpfad geladen werden konnte. Normalerweise ist das zeigt an, dass wir zuvor versucht haben, eine Klasse aus der .__ zu laden. Klassenpfad, aber es ist aus irgendeinem Grund fehlgeschlagen - jetzt versuchen wir es erneut. Aber wir werden nicht einmal versuchen, es zu laden, weil wir nicht Laden Sie es früher. Der frühere Fehler könnte eine .__ sein. ClassNotFoundException oder ein ExceptionInInitializerError (zeigt einen Fehler im statischen Initialisierungsblock an ) Oder eine beliebige Anzahl anderer. Probleme. Der Punkt ist, ein NoClassDefFoundError ist nicht notwendigerweise ein Klassenpfadproblem.

für Ähnlichkeiten und Unterschiede

27
Premraj

Sie können die folgende Maven-Abhängigkeit in Ihrer POM-Datei verwenden. Andernfalls können Sie die folgenden zwei Gläser aus dem Netz herunterladen und Ihrem Build-Pfad 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 Gläser 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

9
Manas Mukherjee

Überprüfen Sie in Deployment Assembly, 

Ich habe den gleichen Fehler, wenn ich die Kriegsdatei mit der "maven clean install" -Methode generiere und manuell implementiere, funktioniert es gut, aber wenn ich die Laufzeitumgebung (Eclipse) benutze, treten die Probleme auf.

Die Lösung für mich (für Eclipse IDE) gehe zu: "proyect properties" -> "Deployment Assembly" -> "Hinzufügen" -> "das benötigte Jar", in meinem Fall Java "Build-Pfad-Einträge" . Vielleicht kann ein wenig helfen!

5
perezmirabile

Basierend auf dem Stacktrace benötigt eine intuitive Klasse com.intuit.ipp.aggcat.util.SAML2AssertionGenerator einen Saml-Jar im Klassenpfad.

Eine saml-Klasse org.opensaml.xml.XMLConfigurator benötigt in der Folge log4j, die sich im WAR befindet, aber nicht finden kann.

Eine Erklärung dafür ist, dass der Klasse XMLConfigurator, der log4j benötigt, nicht in der WAR, sondern in einem Downstream-Classloader gefunden wurde. könnte ein saml-Glas im Krieg fehlen?

Der Klasse XMLConfigurator, der log4j benötigt, kann ihn nicht auf der Ebene des Classloaders finden, mit der er geladen wurde. Die Version von log4j 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") );

Wenn Sie Java 7 verwenden, werfen Sie einen Blick auf jHades . Es ist ein Tool, das ich zur Behebung solcher Probleme entwickelt habe. 

Um zu sehen, was los ist, können Sie die Ergebnisse der Klassenpfadabfragen oben posten. Für welchen Container geschieht dies, Tomcat, Steg? Es wäre besser, den gesamten Stacktrace mit allen durch verursachten in Pastebin zu speichern, nur für den Fall.

4

Hatte das gleiche Problem, es wurde in der Tat von Weblogic verursacht, das dumm seine eigene opensaml-Implementierung verwendete. Um es zu lösen, müssen Sie ihm sagen, dass er Klassen aus WEB-INF/lib für dieses Paket in weblogic.xml laden soll:

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

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

2
Denis Tulskiy

Java.lang.ClassNotFoundException gibt an, dass die Klasse im Klassenpfad nicht gefunden wird Möglicherweise ist die Version von log4j nicht kompatibel. Überprüfen Sie die log4j-Version auf eine andere Version. 

1
Dharmraj

Ich hatte das gleiche Problem, für mich wurde das Problem behoben:
Klicken Sie mit der rechten Maustaste auf das Projekt -> Maven -> Projekt aktualisieren

 maven -> update project

0
user648026