it-swarm.com.de

Fehler: Servlet Jar wurde nicht geladen ... Beleidigende Klasse: javax/servlet/Servlet.class

Ich erhalte folgende Fehlermeldung:

INFO: validateJarFile (C:\dev\server\Tomcat6\webapps Sempedia\WEB-INF\lib\servlet-api.jar) - JAR wurde nicht geladen. Siehe Servlet Spec 2.3, Abschnitt 9.7.2. Beleidigende Klasse: javax/servlet/Servlet.class

Die vorhandenen Ressourcen geben an, dass dies auf einen Konflikt mit der Datei servlet.jar oder in meinem Fall namens servlet-api.jar zurückzuführen ist. Ich habe alle anderen Projekte aus dem Ordner/webapps entfernt. Ich habe die Datei servlet-api.jar aus dem Verzeichnis Tomcat6/lib genommen und das und nur das dem Build-Pfad für das Projekt hinzugefügt ist immer noch ein Konflikt.

Wenn ich versuche, die Anwendung auszuführen, erhalte ich die folgende Stapelablaufverfolgung.

org.Apache.jasper.JasperException: Klasse für JSP kann nicht kompiliert werden: 

In Zeile: 22 in der generierten Java-Datei .__ ist ein Fehler aufgetreten. Die Methode getJspApplicationContext (ServletContext) ist für den Typ JspFactory undefiniert

Stacktrace:

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)

30
Ankur

Dies ist ein Zeichen der Klassenpfadverschmutzung. Die JSP/Servlet-API-Bibliotheken sind von der Anwendungsserverimplementierung abhängig und gehören im Falle von Tomcat 6 in den Ordner Tomcat/lib und sollten in keinesfalls an eine andere Stelle verschoben oder dupliziert werden. Es ist ein Rezept für Portabilitätsprobleme und Kollisionen beim Klassenladen, wie Sie es jetzt erlebt haben. Die Bibliotheken in webapp haben beim Klassenladen Vorrang. Wenn der servlet-api.jar dort angetroffen wird, sucht er nach seinen Abhängigkeiten, die dort aber offensichtlich vermisst wurden.

Sie müssen alle appserver-spezifischen Bibliotheken aus dem Webapp/WEB-INF/lib der Webapp entfernen. Sie sollten nur webapp-spezifische Bibliotheken dort ablegen. Behalten Sie appserver-spezifische Bibliotheken im eigenen Standardklassenpfad des Appservers, in Ihrem Fall Tomcat/lib. Lass es unberührt. Sie können höchstens Bibliotheken hinzufügen, die Sie unter allen Webanwendungen dort freigeben möchten, oder noch besser den shared.loader in Tomcat/conf/catalina.properties dafür konfigurieren.

Entfernen Sie ggf. auch appserver- und webapp-spezifische Bibliotheken aus den Ordnern JDK/lib und JRE/lib. Ich habe zu oft gesehen, dass einige Starter die Bibliotheken dort verschieben/kopieren, weil "sonst nicht kompiliert" wird. Sie sollten niemals Nicht-JRK/JRE-spezifische Bibliotheken dort kopieren. Es ist auch ein Rezept für Probleme mit der Portabilität. Beim Kompilieren von Klassen mit javac sollten Sie das -cp-Argument verwenden, um die abhängigen Bibliotheken anzugeben.

Update: Im Falle eines IDE (Sie scheinen eines zu verwenden, wenn Sie über "Erstellungspfad" sprechen), müssen Sie das Webprojekt einem Anwendungsserver zuordnen. In Eclipse haben Sie beispielsweise die Möglichkeit, dies während der Erstellung eines Dynamic Web Project zu tun. Sie müssen die Serverinstanz vor der Projekterstellung in Eclipse integrieren. Sie können dies über die Servers-Ansicht tun (vorausgesetzt, Sie verwenden Eclipse für Java EE (Entwickler, andernfalls ein Upgrade). Sie können es auch später über den Eintrag Servers in den Projekteigenschaften ändern. Wählen Sie einen Server aus, den Sie als "Standard" -Server verwenden möchten, und seine Bibliotheken werden automatisch in den Erstellungspfad des Projekts aufgenommen. Es ist absolut nicht nötig, sie an einen anderen Ort zu kopieren oder zu verschieben. Siehe auch Wie importiere ich die javax.servlet-API in mein Eclipse-Projekt?

40
BalusC

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

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

    <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>servlet-api</artifactId>
        <version>2.5</version>
        <scope>provided</scope>
    </dependency>

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

    <dependency>
        <groupId>com.example</groupId>
        <artifactId>frob-driver-core</artifactId>
        <version>1.0.1</version>
        <exclusions>
            <exclusion>
                <artifactId>servlet-api</artifactId>
                <groupId>javax.servlet</groupId>
            </exclusion>
        </exclusions>
    </dependency>
20
Raedwald

Sie dürfen keine Klassen bereitstellen, die diejenigen überschreiben, die in der Servlet-Spezifikation definiert sind, die vom Web-Container bereitgestellt wird. Sie können die Spezifikation von herunterladen

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

und überzeugen Sie sich selbst. Abschnitt 9.7.2 befindet sich auf der physischen Seite 63.

Servlet 2.3 ist eine ziemlich alte Version, die auf eine alte Version von Tomcat hinweist. Gibt es einen bestimmten Grund, warum Sie keine neuere verwenden?

Die erste Fehlermeldung, die Sie erhalten haben, war, dass Tomcat die Servlet-JAR nicht laden muss, da sie bereits eine enthält und Konflikte vermeiden möchte.

Sie können die Warnung normalerweise ignorieren. Wenn Sie nicht möchten, dass es angezeigt wird, müssen Sie die Servlet-Dose aus Ihrem Projekt verschieben, anstatt die von Tomcat zu verwenden. Durch die Übernahme des Tomcat in Ihr Projekt ist es Ihnen gelungen, Tomcat zu überzeugen, es von Ihrer Web-App zu laden und nicht von dort, wo es erwartet wurde. Dies führte zu einem Klassenladeproblem, wie in der Antwort von BalusC erwähnt.

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

2
Jamie McCrindle

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

1
sergeyan

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

Wenn Sie die Vererbung in Maven-Projekten verwenden, müssen Sie muss diese Konfiguration in die übergeordnete Datei pom.xml Aufnehmen. Sie werden einen Abschnitt <parent>...</parent> In Ihrer pom.xml haben wenn Sie Vererbung verwenden. Also haben Sie so etwas in Ihrem Elternteil pom.xml:

<groupId>some.groupId</groupId>
<version>1.0</version>
<artifactId>someArtifactId</artifactId>
<packaging>pom</packaging>
<modules>
    <module>child-module-1</module>
    <module>child-module-2</module>
</modules>
<dependencies>
    <dependency>
        <groupId>javax.servlet</groupId>
        <artifactId>servlet-api</artifactId>
        <version>2.5</version>
        <scope>provided</scope>
    </dependency>
    <dependency>
        <groupId>javax.servlet.jsp</groupId>
        <artifactId>jsp-api</artifactId>
        <version>2.1</version>
        <scope>provided</scope>
    </dependency>
</dependencies>
0
lmiguelmh