Impossible de comstackr la classe pour JSP: le type java.util.Map $ Entry ne peut pas être résolu. Il est référencé indirectement à partir des fichiers .class requirejs

Je ne peux pas obtenir tomcat7 pour comstackr des jsps. Il suffit de lancer l’exemple des servlets et le service est opérationnel. Je suis en cours d’exécution oracle java 8.

Est-ce que quelqu’un peut-il me montrer la bonne direction?

Voici le stacktrace:

type Exception report message Unable to comstack class for JSP: description The server encountered an internal error that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: Unable to comstack class for JSP: An error occurred at line: 1 in the generated java file The type java.util.Map$Entry cannot be resolved. It is indirectly referenced from required .class files Stacktrace: org.apache.jasper.comstackr.DefaultErrorHandler.javacError(DefaultErrorHandler.java:102) org.apache.jasper.comstackr.ErrorDispatcher.javacError(ErrorDispatcher.java:331) org.apache.jasper.comstackr.JDTComstackr.generateClass(JDTComstackr.java:468) org.apache.jasper.comstackr.Comstackr.comstack(Comstackr.java:378) org.apache.jasper.comstackr.Comstackr.comstack(Comstackr.java:353) org.apache.jasper.comstackr.Comstackr.comstack(Comstackr.java:340) org.apache.jasper.JspCompilationContext.comstack(JspCompilationContext.java:646) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:357) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334) javax.servlet.http.HttpServlet.service(HttpServlet.java:728) note The full stack trace of the root cause is available in the Apache Tomcat/7.0.35 logs. 

Le code ressemble à ceci et c’est l’exemple de code de tomcat7, donc je suppose que c’est correct.

    JSP 2.0 Examples - Hello World SimpleTag Handler   

JSP 2.0 Examples - Hello World SimpleTag Handler


This tag handler simply echos "Hello, World!" It's an example of a very basic SimpleTag handler with no body.


Result:

Vous devez utiliser une version plus récente de tomcat qui prend en charge JDK 8.

Je peux confirmer que apache-tomcat-7.0.35 n’a pas de support pour JDK8, je peux également confirmer que apache-tomcat-7.0.50 est compatible avec JDK8.

Le format de classe de JDK8 a changé et c’est la raison pour laquelle Tomcat n’est pas capable de comstackr des JSP. Essayez d’obtenir une version plus récente de Tomcat.

J’ai récemment eu le même problème. C’est un bogue dans Tomcat, ou plutôt, JDK 8 a un format de fichier de classe légèrement différent de celui des versions antérieures à JDK8. Cela provoque une incohérence et Tomcat ne peut pas comstackr les JSP dans JDK8.

Voir les références suivantes:

  • Comstackr les JSP avec JDK 1.8 dans Tomcat 8
  • la compilation réussit dans java7 mais échoue dans java8

Parce que nous courons sur Ubuntu 12.04 LTS et que le dernier package officiel tomcat7 supporté est 7.0.26, nous ne pouvons pas facilement mettre à jour l’intégralité de tomcat.

Afin de tester avec le jdk8, j’ai pu résoudre ce problème en changeant certains jars par rapport à leur dernière version 7.0. *.

J’ai changé jasper.jar, jasper-el et tomcat-util pour la version 7.0.53 et ajouté ecj-4.3.1.jar. Cela ramène l’application en ligne.

MAIS … j’ai également changé le contenu packagé avec ceci, alors peut-être serait-il préférable de télécharger l’intégralité de Tomcat et de l’utiliser en tant que paquetage de paquetage. Donc, s’il vous plaît, ne voyez cela que comme un truc ou une solution rapide très sale.

Si vous utilisez maven, vous pouvez append le plug-in tomcat7-maven à votre fichier pom.xml. Ce plug-in exécutera le projet sur le conteneur de servlets Tomcat version 7.0.47 qui prend en charge JDK 1.8.

    org.apache.tomcat.maven tomcat7-maven-plugin 2.2   ./src/main/webapp/META-INF/context.xml 8080     com.oracle ojdbc6 11.2.0.4.0     

J’espère que c’est utile! Merci

De la base de connaissances JIRA :

 Symptoms 

Les actions de workflow peuvent être inaccessibles

  1. JIRA peut lancer des exceptions à l’écran
  2. Une ou les deux conditions suivantes peuvent exister:

Ce qui suit apparaît dans le fichier atlassian-jira.log:

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

_

 Cause: 

Le conteneur Tomcat met en cache les fichiers .java et .class générés par l’parsingur JSP utilisé par l’application Web. Parfois, ceux-ci sont corrompus ou introuvables. Cela peut se produire après un correctif ou une mise à niveau contenant des modifications apscopes aux JSP.

 Resolution 

1.Supprimez le contenu du dossier / work si vous utilisez JIRA autonome ou / work si vous utilisez une installation EAR / WAR. 2. Vérifiez que l’utilisateur exécutant le processus d’application JIRA dispose des droits d’access en lecture / écriture sur le répertoire / work. 3. Redémarrez le conteneur d’application JIRA pour reconstruire les fichiers.

Ajoutez cette importation <%@page import="java.util.Map" %>

Cela a fonctionné pour moi, mais j’avais aussi besoin d’append <% @ page import = "java.util.HashMap"%>. Il semble que la réponse ci-dessus soit vraie, que si vous avez le nouveau Tomcat, vous n’aurez peut-être pas besoin d’append ces lignes, mais comme je ne pouvais pas modifier tout mon système, cela fonctionnait.
Je vous remercie

Confronté exactement au même problème lors de la mise à niveau de mon application de java 6 vers java 8 sur tomcat 7.0.19. Après la mise à niveau de tomcat vers 7.0.59, ce problème est résolu.

Essayez d’append <%@page import="java.util.Map.Entry"%> à votre fichier jsp

Il y a beaucoup de réponses correctes / identiques, mais pour les références futures:

Même chose pour Tomcat 7. Sachez que la mise à jour des versions de vos frameworks utilisés (comme proposé dans d’autres questions similaires) ne suffit pas.

Vous devez également mettre à jour la version du plug-in Tomcat. Ce qui a fonctionné pour moi, en utilisant Java 7, était la mise à niveau vers la version 2.2 de tomcat7-maven-plugin (= Tomcat 7.0.47).

Je viens de parler du même problème. J’utilisais IntelliJx64 avec Tomcat7.0.32 avec jdk.8.0.102 . Il n’y avait pas de problème alors. J’ai pu accéder directement à mon déploiement localhost: [port] sans append [mywebapp] ou / ROOT .

Lorsque j’ai essayé de migrer vers éclipse néon , je suis tombé sur le même bug qui est discuté lorsque j’ai essayé de définir le chemin comme une chaîne vide . Lorsque j’ai appliqué l’environnement d’exécution à Java7 et défini des modules pour le vider, cela n’a pas résolu le problème des orteils. Cependant, lorsque j’ai changé mon installation tomcat en 7.072 et changé manuellement la configuration du chemin de contexte en path = “”, le problème a été résolu en éclipse. (Vous pouvez manipuler le chemin via un serveur double-clic et passer à l’onglet Module également.)

Je me demande comment IntelliJ ne posait aucun problème avec le même bogue qui était censé être lié à la version d’installation de Tomcat?

Il semble également y avoir une relation avec l’IDE en cours d’utilisation.

Je me suis heurté à cela auparavant, comme d’autres l’ont dit: il suffit de upgrade jetty plugin à upgrade jetty plugin

si vous utilisez maven

aller à jetty plugin dans pom.xml et le mettre à jour à

  org.eclipse.jetty jetty-maven-plugin 9.3.0.v20150612  3  ${jetty.port} 60000  foo ${jetty.stop.port}   

j’espère que cela vous aidera