Fehler: Servlet-Jar nicht geladen … Beleidigende class: javax / servlet / Servlet.class

Ich erhalte den folgenden Fehler:

INFO: validateJarFile (C: \ dev \ server \ tomcat6 \ webappsSempedia \ WEB-INF \ lib \ servlet-api.jar) – jar nicht geladen. Siehe Servlet Spec 2.3, Abschnitt 9.7.2. Beleidigende class: javax / servlet / Servlet.class

Die vorhandenen Ressourcen dort draußen sagen, dass es aufgrund eines Konflikts mit der servlet.jar oder in meinem Fall namens servlet-api.jar-Datei ist. Ich habe alle anderen Projekte aus dem Ordner / webapps entfernt, ich habe die Datei servlet-api.jar genommen, die sich im Verzeichnis tomcat6 / lib befand, und das nur zum Projektbuildpfad hinzugefügt, so dass ich nicht sehen kann, wie dort ist immer noch ein Konflikt.

Wenn ich versuche, die Anwendung auszuführen, bekomme ich die folgende Stapelverfolgung.

org.apache.jasper.JasperException: Die class für JSP kann nicht kompiliert werden:

Ein Fehler ist bei Zeile 22 in der generierten Java-Datei aufgetreten. Die Methode getJspApplicationContext (ServletContext) ist für den Typ JspFactory nicht definiert

Stapelverfolgung:

org.apache.jasper.compiler.DefaultErrorHandler.javacError (DefaultErrorHandler.java:92) org.apache.jasper.compiler.ErrorDispatcher.javacError (ErrorDispatcher.java:330) org.apache.jasper.compiler.JDTCompiler.generateClass (JDTCompiler. java: 439) org.apache.jasper.compiler.Compiler.compile (Compiler.java:334) org.apache.jasper.compiler.Compiler.compile (Compiler.java:312) org.apache.jasper.compiler.Compiler. compile (Compiler.java:299) org.apache.jasper.JspCompilationContext.compile (JspCompilationContext.java:586) org.apache.jasper.servlet.JspServletWrapper.service (JspServletWrapper.java:317) org.apache.jasper.servlet. JspServlet.serviceJspFile (JspServlet.java:342) org.apache.jasper.servlet.JspServlet.service (JspServlet.java:267) javax.servlet.http.HttpServlet.service (HttpServlet.java:717)

Dies ist ein Zeichen der classnpfadverschmutzung. Die JSP / Servlet-API-Bibliotheken sind abhängig von der Anwendungsserverimplementierung und gehören im Fall von Tomcat 6 in den Tomcat/lib Ordner und sollten auf keinen Fall irgendwo anders verschoben oder dupliziert werden. Es ist ein Rezept für Portabilitätsprobleme und Kollisionen beim Classloading, wie Sie es jetzt kennen. Die Bibliotheken in webapp haben beim Classloading Vorrang. Wenn das servlet-api.jar dort angetroffen wird, sucht es dort wiederum nach seinen Abhängigkeiten, die dort aber offensichtlich fehlten.

Sie müssen alle anwenderspezifischen Bibliotheken aus der Webapp/WEB-INF/lib der Webanwendung entfernen. Sie sollten nur webapp-spezifische Bibliotheken einbinden. Bewahre anwenderserverspezifische Bibliotheken im eigenen classnpfad des Appservers auf, der in deinem Fall der Tomcat/lib ist. Halte es unberührt. Sie können höchstens Bibliotheken hinzufügen, die Sie für alle Webapps dort freigeben möchten, oder noch besser, Sie konfigurieren den shared.loader in Tomcat/conf/catalina.properties dafür.

Entfernen Sie auch alle anwendungsserverspezifischen und webappspezifischen Bibliotheken aus den Ordnern JDK/lib und JRE/lib . Ich habe zu oft gesehen, dass einige Starter die Bibliotheken dort verschieben / kopieren, weil “es sonst nicht kompiliert”. Sie sollten niemals Nicht-JRK / JRE-spezifische Bibliotheken darin kopieren. Es ist auch ein Rezept für Portabilitätsprobleme. Wenn Sie classn mit javac kompilieren, sollten Sie das Argument -cp , um die abhängigen Bibliotheken anzugeben.

Update : Im Falle einer IDE (Sie scheinen eine zu verwenden, da Sie über “Build-Pfad” sprechen), müssen Sie das Webprojekt einem Anwendungsserver zuordnen. In Eclipse haben Sie zum Beispiel die Möglichkeit, dies während der Erstellung eines dynamischen Webprojekts zu tun. Sie müssen die Serverinstanz vor der Erstellung des Projekts in Eclipse integrieren. Sie können dies über die Servers Ansicht tun (vorausgesetzt, Sie verwenden Eclipse für Java EE- Entwickler , sonst ein Upgrade). Sie können es später auch über den Eintrag Server in den Projekteigenschaften ändern. Wählen Sie eine, die Sie als “Standard” -Server verwenden möchten, und dann werden seine Bibliotheken automatisch in den Build-Pfad des Projekts aufgenommen. Es ist absolut nicht nötig, sie woanders zu kopieren / zu verschieben. Siehe auch Wie importiere ich die javax.servlet-API in mein Eclipse-Projekt?

Wie andere Antworten sagen, liegt dies daran, dass Ihr WAR die Servlet-API-classn enthält, dies aber nicht tun sollte.

Wenn Sie Maven zum Erstellen Ihres Projekts verwenden, sollten Sie Maven bitten, die Servlet-API beim Kompilieren und Testen verfügbar zu machen, aber nicht in die WAR-Datei aufzunehmen. Wie die Maven-Dokumentation zum Abhängigkeitsbereich sagt, sollten Sie den provided Bereich für die Servlet-API verwenden:

   javax.servlet servlet-api 2.5 provided  

Möglicherweise müssen Sie die Servlet-API auch explizit als transitive Abhängigkeit ausschließen, wenn einige Ihrer Abhängigkeiten die Servlet-API als Kompilierabhängigkeit verwenden:

   com.example frob-driver-core 1.0.1   servlet-api javax.servlet    

Sie dürfen keine classn bereitstellen, die diejenigen überschreiben, die in der Servlet-Spezifikation definiert sind, die vom Webcontainer bereitgestellt werden. Sie können die Spezifikation von herunterladen

http://www.jcp.org/aboutJava/communityprozess/final/jsr053/

und überprüfe es selbst. Abschnitt 9.7.2 befindet sich auf der physischen Seite 63.

Servlet 2.3 ist eine ziemlich alte Version, die eine alte Version von Tomcat anzeigt. Gibt es einen bestimmten Grund, warum Sie keinen neueren verwenden?

Die erste Fehlermeldung, die Sie bekommen haben, war, weil Tomcat das Servlet-Jar nicht laden muss, weil es bereits eins hat und Konflikte vermeiden will.

Sie können die Warnung normalerweise ignorieren. Wenn Sie nicht möchten, dass es angezeigt wird, müssen Sie das Servlet-Jar aus Ihrem Projekt verschieben, anstatt das Tomcat zu verwenden. Indem Sie den Tomcat eins nehmen und es in Ihr Projekt einfügen, haben Sie es geschafft, Tomcat davon zu überzeugen, es von Ihrer Webapp zu laden, anstatt von wo es erwartet wurde, was zu einem classnladeproblem führte, wie in der BalusC Antwort erwähnt.

Bearbeiten: Das obige wurde bearbeitet, um zu klären, was passiert ist, nachdem Sie das Servlet-API-Glas von Tomcat in Ihre Webanwendung (und Attribut BalusC) eingefügt haben.

In der Tat hatte ich so einen Fehler und App. konnte nicht gestartet werden, da einige der .JAR in WEB-INF/lib aus irgendeinem Grund .JAR (Großbuchstaben) anstelle von .jar . Stellen Sie also sicher, dass alle Gläser gültig sind.

Ausschlüsse und provided Abhängigkeiten funktionieren nicht in untergeordneten Projekten.

Wenn Sie inheritance in Maven-Projekten verwenden, müssen Sie diese Konfiguration in die übergeordnete Datei pom.xml . Sie werden einen Abschnitt ... in Ihrer pom.xml haben, wenn Sie inheritance verwenden . Sie werden also in Ihrem Elternteil so etwas wie pom.xml :

 some.groupId 1.0 someArtifactId pom  child-module-1 child-module-2    javax.servlet servlet-api 2.5 provided   javax.servlet.jsp jsp-api 2.1 provided