Klasse kann für JSP nicht kompiliert werden: Der Typ Java.util.Map $ Entry kann nicht aufgelöst werden. Es wird indirekt auf erforderliche .class-Dateien verwiesen

Das Klassenformat von JDK8 hat sich geändert. Aus diesem Grund kann Tomcat JSPs nicht kompilieren. Versuchen Sie, eine neuere Version von Tomcat zu erhalten.

Ich hatte kürzlich das gleiche Problem. Dies ist ein Fehler in Tomcat bzw. JDK 8 hat ein etwas anderes Klassendateiformat als frühere JDK8-Versionen. Dies führt zu Inkonsistenzen und Tomcat kann JSPs in JDK8 nicht kompilieren.

Siehe folgende Referenzen:

• JSPs mit JDK 1.8 in Tomcat 8 übersetzen
• Kompilierung in Java7 erfolgreich, aber in Java8 fehlgeschlagen

Wenn Sie maven verwenden, können Sie das Tomcat7-maven-plugin zu Ihrer pom.xml hinzufügen und es wird einwandfrei laufen. Dieses Plugin führt das Projekt auf der Tomcat-Servlet-Container-Version 7.0.47 aus, die JDK 1.8 unterstützt. 

    <plugins>
    <plugin>
     <groupId>org.Apache.Tomcat.maven</groupId>
     <artifactId>Tomcat7-maven-plugin</artifactId>
     <version>2.2</version>
     <configuration>
<!-- Include context file for Datasource configuration -->
     <contextFile>./src/main/webapp/META-INF/context.xml</contextFile>
    <port>8080</port>
     </configuration>
     <dependencies>
<!-- Include jdbc driver dependency if using datasource (in my case Oracle) -->
    <dependency>
        <groupId>com.Oracle</groupId>
        <artifactId>ojdbc6</artifactId>
        <version>11.2.0.4.0</version>
    </dependency>
  </dependencies>
    </plugin>
    </plugins>

Hoffe das ist nützlich! Vielen Dank

Da wir auf Ubuntu 12.04 LTS laufen und das neueste offizielle unterstützte Tomcat7-Paket 7.0.26 ist, können wir den gesamten Tomcat nicht ohne Weiteres aktualisieren.

Um mit dem jdk8 testen zu können, konnte ich dieses Problem beheben, indem einige Gläser gegen die neueste Version 7.0. * Ausgetauscht wurden.

Ich habe jasper.jar, jasper-el und Tomcat-util auf die Version 7.0.53 umgestellt und ecj-4.3.1.jar hinzugefügt. Damit ist die Anwendung wieder online.

ABER ... auch ich habe hiermit den Inhalt des Pakets geändert. Vielleicht wäre es besser, den ganzen Tomcat herunterzuladen und ihn selbst als vermischte Pakete zu verwenden. Bitte sehen Sie dies nur als sehr schmutzigen Quickhack oder Workaround.

Diesen Import hinzufügen <%@page import="Java.util.Map" %>

Dies funktionierte für mich, aber ich musste auch <% @ page import = "Java.util.HashMap"%> ..__ hinzufügen. Es scheint, dass die obige Antwort wahr ist, dass Sie den neueren Tomcat möglicherweise nicht benötigen diese Zeilen hinzuzufügen, aber da ich mein gesamtes System nicht ändern konnte, funktionierte dies.
Vielen Dank

Versuchen Sie, <%@page import="Java.util.Map.Entry"%> zu Ihrer JSP-Datei hinzuzufügen

Es gibt viele richtige/gleiche Antworten, aber für zukünftige Referenzen:

Dasselbe gilt für Tomcat 7. Beachten Sie, dass das Aktualisieren nur der Versionen Ihrer verwendeten Frameworks (wie in anderen ähnlichen Fragen vorgeschlagen) nicht ausreicht.

Sie müssen auch die Version des Tomcat-Plugins aktualisieren. Was für mich mit Java 7 funktionierte, war ein Upgrade auf Version 2.2 von Tomcat7-maven-plugin (= Tomcat 7.0.47).

Aus der JIRA-Wissensdatenbank :

Symptoms

Workflow-Aktionen sind möglicherweise nicht verfügbar

1. JIRA kann Ausnahmen auf dem Bildschirm auslösen
2. Eine oder beide der folgenden Bedingungen können vorliegen:

In atlassian-jira.log wird Folgendes angezeigt:

     2007-12-06 10:55:05,327 http-8080-Processor20 ERROR [500ErrorPage] 
     Exception caught in500 page Unable to compile class for JSP
    org.Apache.jasper.JasperException: Unable to compile class for JSP
   at org.Apache.jasper.JspCompilationContext.compile(JspCompilationContext.Java:572)
   at org.Apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.Java:305)

_

Cause:

Der Tomcat-Container speichert .Java- und .class-Dateien, die von der .__-Datei generiert wurden, im Cache. JSP-Parser werden von der Webanwendung verwendet. Manchmal bekommen diese beschädigt oder kann nicht gefunden werden. Dies kann nach einem Patch oder Upgrade auftreten das enthält Änderungen an JSPs.

Resolution

1.Löschen Sie den Inhalt des/work-Ordners, wenn Sie Standalone-JIRA verwenden, oder/work, wenn Sie die EAR/WAR-Installation verwenden . 2. Stellen Sie sicher, dass der Benutzer, der den JIRA-Anwendungsprozess ausführt, über die Lese-/Schreibberechtigung für das Verzeichnis/work verfügt. 3. Starten Sie den JIRA-Anwendungscontainer neu, um die Dateien neu zu erstellen.

Beim Upgrade meiner Anwendung von Java 6 auf Java 8 unter Tomcat 7.0.19 ..__ trat genau das gleiche Problem auf. Nach dem Upgrade von Tomcat auf 7.0.59 wurde dieses Problem behoben.

Ich bin schon mal darauf gestoßen, wie andere sagten: einfach upgrade jetty plugin 

wenn Sie maven verwenden 

gehe zu jetty plugin in pom.xml und aktualisiere es auf 

<plugin>
    <groupId>org.Eclipse.jetty</groupId>
    <artifactId>jetty-maven-plugin</artifactId>
    <version>9.3.0.v20150612</version>
    <configuration>
        <scanIntervalSeconds>3</scanIntervalSeconds>
        <httpConnector>
            <port>${jetty.port}</port>
            <idleTimeout>60000</idleTimeout>
        </httpConnector>
        <stopKey>foo</stopKey>
        <stopPort>${jetty.stop.port}</stopPort>
    </configuration>
</plugin>

hoffe das hilft dir 

Ich habe vor kurzem dasselbe Problem. Ich war mit IntelliJx64 mit Tomcat7.0.32 mit jdk.8.0.102. Es gab damals kein Problem. Ich konnte direkt auf meine Bereitstellung localhost: [Anschluss] zugreifen, ohne [mywebapp] oder / ROOT hinzuzufügen.

Als versuchte, zu Eclipse neon zu migrieren, stießauf den gleichen Fehler, der besprochen wurde, als ich versuchte, den Pfad als leere Zeichenfolgefestzulegen. Als ich die Ausführungsumgebung auf Java7 erzwungen und leere Module eingestellt habe, konnte das Problem nicht gelöst werden. Als ich jedoch meine Tomcat-Installation in 7.072 geändert und die Kontextpfadkonfiguration manuell in path = "" geändert habe, wurde das Problem in Eclipse behoben. (Sie können den Pfad auch mit einem Doppelklick-Server bearbeiten und zur Modul-Registerkarte wechseln.)

Ich wundere mich, wie kam es, dass IntelliJ keine Probleme mit dem gleichen Fehler gab, der mit der Tomcat-Installationsversion in Zusammenhang stehen sollte.

Es scheint auch eine Beziehung zu den verwendeten IDE zu geben.