org.apache.jasper.el.ELContextImpl kann nicht umgewandelt werden, org.apache.jasper.- Laufzeit.ELContextImpl

Ich habe eine web-service-Projekt in java implementiert und es enthält auch jsp-Seiten. Ich installieren Sie es auf jetty 8.1.5 auf meinem Rechner und es funktioniert normal. Aber wenn ich deploy auf einem windows server 2003 mit Steg, 8.1.3, es gibt diese Ausnahme:

org.apache.jasper.el.ELContextImpl cannot be cast to org.apache.jasper.runtime.ELContextImpl

Dies ist der vollständige trace:

java.lang.ClassCastException: org.apache.jasper.el.ELContextImpl cannot be cast to org.apache.jasper.runtime.ELContextImpl
    at org.apache.jasper.runtime.PageContextImpl.evaluateExpression(PageContextImpl.java:1002)
    at org.apache.jsp.home.index_jsp._jspService(org.apache.jsp.home.index_jsp:52)
    at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:111)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:403)
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:492)
    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:378)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:598)
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
    at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:542)
    at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
    at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
    at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:271)
    at org.eclipse.jetty.server.Dispatcher.forward(Dispatcher.java:98)
    at org.eclipse.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:557)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:735)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:848)
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:598)
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
    at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:499)
    at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
    at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
    at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
    at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
    at org.eclipse.jetty.server.Server.handle(Server.java:350)
    at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
    at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)
    at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944)
    at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630)
    at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
    at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:77)
    at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:606)
    at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:46)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:603)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:538)
    at java.lang.Thread.run(Unknown Source)

Jede Idee, was diese Ausnahme-und wie man es beheben?

Sind Sie mit maven?
Es scheint nicht wirklich zu gelten, so bin nicht mit diese als eine "Antwort". Jedoch, wird diese Fehlermeldung tritt in der Regel (für mich!) wenn ich eine Kopie der servlet-api 2.4 in den classpath vor 2.5 oder 3.0. Können Sie sich vergewissern, dass auf dem server, der ausfällt?

InformationsquelleAutor Sami | 2012-09-12

  1. 11

    Dass kann passieren, wenn Ihre webapp Schiffe mit servletcontainer-spezifische JAR-Dateien wie jasper.jar, jetty.jar servlet.jar etc in den /WEB-INF/lib für einige unklaren Grund. Dies ist wiederum in Konflikt mit mit einer anderen Versionsangabe JAR-Datei auf dem Ziel-servletcontainer.

    Entfernen, servletcontainer-spezifischen JAR-Datei aus Ihre webapp ist /WEB-INF/lib. Es dort nicht hin gehört. Es soll bereits geliefert durch den servletcontainer selbst.

    Siehe auch:

    Ich habe /WEB-INF/lib, und konnte keine finden jasper.jar Datei. Könnten Sie bitte erklären, was meinst du mit einem servletcontainer-spezifische jasper.jar?
    Ich fand jetty-spezifische jar-Dateien in den gleichen Ordner und Sie sind in der version 8.1.5 spezifische wie: jetty-continuation-8.1.5.v20120716.jar, jetty-http-8.1.5.v20120716.jar ... ich habe versucht, diese zu entfernen, aber dann bekam ich HTTP 503-service nicht verfügbar ist und Ausnahmen, wenn ich starten Sie jetty. Ist es ein Problem, wenn ich die Bereitstellung auf jetty 8.1.3 mit diesen 8.1.5 Gläser versendet, in der war-Datei.
    Ich habe eine neue question und Liste aller Gläser gibt.
    Warum erstellen Sie eine neue Frage? Kann es nicht hier aktualisiert werden?
    Vielen, vielen Dank!

    InformationsquelleAutor BalusC

  2. 5

    WENN Sie mit maven (fragte ich, auf einen Kommentar ohne Antwort), können Sie vermeiden, konfliktträchtige Gläser mit einem "versehen" Umfang. Wenn Sie es bereitstellen, die für die Produktion, Gläser sind nicht im Lieferumfang enthalten.

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

    Ich bin mir nicht sicher über die jettys Gläser, aber es ist wahrscheinlich das gleiche.

    WENN Sie sind NICHT mit maven, sollten Sie Ihre konfliktträchtige Gläser (servlets und Steg) auf Ihrer develompent container lib-Ordner und entfernen Sie Sie aus Ihren Anwendungen WEB-INF/lib-Ordner.

    InformationsquelleAutor jpaoletti

  3. 4

    Wenn der Ordner /WEB-INF/lib Ihrer webapp nicht enthalten jasper.jar (siehe BalusC' Antwort), überprüfen Sie bitte, ob ein anderes webapp läuft in den container. Dann überprüfen, ob das webapp enthält eine jasper.jar in dem Ordner /WEB-INF/lib. Dies geschah, um uns. Das entfernen werden jasper.jar aus diesen webapps (sic!), das problem konnte gelöst werden. Offensichtlich, webapps sind nicht isoliert für meach anderen, wie Sie sein sollten. Das problem erschien so wechselten wir von Tomcat6 zu Tomcat7 und jasper.jar (version 6) gebündelt wurde versehentlich mit einem unserer webapps.

    Ja, es war die bestehenden in eine andere web-app und entfernen Sie das Problem beseitigt haben. Aber ich verstehe immer noch nicht, warum dies geschah, als ich gepostet ein Frage auf der jetty-Foren, und Sie sagten, jede app führt seinen eigenen class loader.

    InformationsquelleAutor rwitzel

  4. 3

    Abgesehen von den Antworten erwähnt, watch out für eine weitere Sache. Ich habe einen anderen Krieg eingesetzt, die unter der gleichen Tomcat-7.0.42 Instanz, die hatte eine jsp-2.1-6.0.2.jar unter WEB-INF/lib. Dieses jar hat org.apache.jasper.- Laufzeit.ELContextImpl Klasse.

    Mein Verständnis war, dass jeder webapp hat seinen eigenen classloader und class-Dateien geladen, die von einer webapp ist nicht sichtbar für das andere webapp. Noch als nichts funktionierte habe ich entfernt, der andere Krieg, die hatte, die jsp.jar und neu gestartet, meine tomcat und zu meiner überraschung die Ausnahme war, nicht mehr kommen. Irgendwie ist diese Klasse war immer geladen und das Problem verursacht.

    Das interessante an der Sache ist, dass diese beiden Kriege, die arbeiten hervorragend in Tomcat 6.x.

    InformationsquelleAutor saurabh

  5. 0

    Ich vor dem gleichen problem, und habe versucht, alle Vorschläge, keine für mich gearbeitet. Schließlich fand ich heraus, dass das Problem verursacht wurde, nach der Verwendung von Spring Boot überschreiben meine tomcat-version, da hatte ich 

    <parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>1.1.0.M2</version>

    Entfernen der Feder Boot löst das problem. Diese Antwort könnte die Lösung für die Verwendung von Spring Boot + Maven + Tomcat 8.

    InformationsquelleAutor Saeed

  6. 0

    Für mich (Steg 8.1.14), das genaue Fehlermeldung wurde tatsächlich verursacht durch eine andere webapp in der gleichen Jetty-container. Sind Sie mit mehr als einem webapps?

    Wenn ich mich richtig erinnere (es ist schon zwei Jahre oder so jetzt), das problem wurde verursacht, weil der Konflikt Gläser von einer anderen web-app bereitgestellt, die in der gleichen Jetty-container. Ich landete zu splitten und beide arbeiteten gut.

    InformationsquelleAutor Mr Auni

Schreibe einen Kommentar