Comment installer JSTL? L'URI absolu: http://java.sun.com/jstl/core ne peut pas être résolu

135

Je ne sais pas ce que j'ai mal fait, mais je ne peux pas inclure JSTL. J'ai jstl-1.2.jar, mais malheureusement je reçois une exception:

org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application
    at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:51)
    at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:409)
    at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:116)
    at org.apache.jasper.compiler.TagLibraryInfoImpl.generateTLDLocation(TagLibraryInfoImpl.java:315)
    at org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:148)
    at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:429)
    at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:492)
    at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1439)
    at org.apache.jasper.compiler.Parser.parse(Parser.java:137)
    at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:255)
    at org.apache.jasper.compiler.ParserController.parse(ParserController.java:103)
    at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:170)
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:332)
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:312)
    at org.apache.jasper.compiler.Compiler.compile(Compiler.java:299)
    at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:586)
    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:317)
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:342)
    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:267)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
    at java.lang.Thread.run(Thread.java:619)

J'ai:

  • pom.xml

    <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>

<dependency>
  <groupId>taglibs</groupId>
  <artifactId>standard</artifactId>
  <version>1.1.2</version>
</dependency>
<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>jstl</artifactId>
  <version>1.2</version>
</dependency>

  • web.xml

    <web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
  version="2.5">

  • index.jsp

    <%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>
<html> 
<head></head>
<body></body>
</html>
jsp  servlets  jstl 
— lukastymo
source
4
J'ai dû ajouter la dépendance des taglibs à côté du jstl et j'ai juste travaillé.
— Christian Vielma

Réponses:

193

org.apache.jasper.JasperException: l'URI absolu: http://java.sun.com/jstl/core ne peut être résolu ni dans web.xml ni dans les fichiers jar déployés avec cette application

Cet URI est pour JSTL 1.0, mais vous utilisez en fait JSTL 1.2 qui utilise des URI avec un /jspchemin supplémentaire (car JSTL, qui a inventé les expressions EL, était depuis la version 1.1 intégrée dans le cadre de JSP afin de partager / réutiliser la logique EL dans JSP simple aussi).

Donc, corrigez l'URI taglib en conséquence en vous basant sur la documentation JSTL :

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

De plus, vous devez absolument vous assurer de ne pas lancer plusieurs fichiers JAR JSTL versionnés différents ensemble dans le chemin de classe d'exécution. C'est une erreur assez courante parmi les utilisateurs de Tomcat. Le problème avec Tomcat est qu'il n'offre pas JSTL prêt à l'emploi et que vous devez donc l'installer manuellement. Cela n'est pas nécessaire sur les serveurs Java EE normaux. Voir aussi Qu'est-ce que Java EE exactement?

Dans votre cas spécifique, votre pom.xml vous indique essentiellement que vous avez jstl-1.2.jar et standard-1.1.2.jar ensemble. C'est faux. Vous mélangez essentiellement JSTL 1.2 API + impl d'Oracle avec JSTL 1.1 impl d'Apache. Vous devez supprimer tout fichierstandard-xxx.jar . Il suffit que l' jstl-1.2.jarest suffisante.

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>jstl</artifactId>
    <version>1.2</version>
</dependency>

Les utilisateurs non-Maven peuvent réaliser la même chose en déposant le fichier physique jstl-1.2.jar dans le /WEB-INF/libdossier du projet d'application Web (ne déposez absolument pas standard.jar ou tout autre fichier .tld lâche!). Retirez-les si nécessaire.

Si vous utilisez réellement un serveur Java EE normal tel que WildFly, Payara, etc. au lieu d'un conteneur de servlet barebones tel que Tomcat, Jetty, etc., vous n'avez pas du tout besoin d'installer explicitement JSTL. Les serveurs Java EE normaux fournissent déjà JSTL. En d'autres termes, vous n'avez pas besoin d'ajouter JSTL pom.xmlni de supprimer des fichiers JAR / TLD dans webapp. Seule la providedcoordonnée Java EE étendue est suffisante:

<dependency>
    <groupId>javax</groupId>
    <artifactId>javaee-api</artifactId>
    <version><!-- 8.0, 7.0, etc depending on your server --></version>
    <scope>provided</scope>
</dependency>

De plus, vous devez également vous assurer que votre web.xmlest déclaré conforme au moins Servlet 2.4 et donc pas comme Servlet 2.3 ou plus ancien. Sinon, les expressions EL à l'intérieur des balises JSTL ne fonctionneraient pas. Choisissez la version la plus élevée correspondant à votre conteneur cible et assurez-vous que vous n'avez <!DOCTYPE>nulle part dans votre web.xml. Voici un exemple compatible Servlet 4.0 (Tomcat 9):

<?xml version="1.0" encoding="UTF-8"?>
<web-app
    xmlns="http://xmlns.jcp.org/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd"
    version="4.0">

    <!-- Config here. -->

</web-app>

Voir également:

— BalusC
source
J'ai changé pour / jsp et: org.apache.jasper.JasperException: L'uri absolu: java.sun.com/jsp/jstl/core ne peut être résolu ni dans web.xml ...
— lukastymo
4
Alors votre chemin de classe est en désordre. Nettoyez-le. Je ne sais pas ce que fait maven et si c'est intelligent, mais pour JSTL 1.2 vous n'avez pas besoin du standardtaglib. Lisez la page d'informations sur les balises pour plus de détails.
— BalusC
4
J'aime vraiment la page wiki JSTL que vous avez créée. Cependant, puisque cette question est le premier succès de Google pour le message d'erreur particulier, je prends la liberté de le modifier et de noter que l'URI "non-jsp" provient de JSTL 1.0.
— kdgregory
2
@kdgregory: Merci :)
— BalusC
1
si vous utilisez Gradle, ajoutez cette dépendance:compile('javax.servlet:jstl:1.2')
— benscabbia
36

@BalusC a tout à fait raison, mais si vous rencontrez toujours cette exception, cela signifie que vous avez mal fait quelque chose. Les informations les plus importantes que vous trouverez se trouvent sur la page d' informations sur les balises SO JSTL .

En gros, il s'agit d'un résumé de ce que vous devez faire pour faire face à cette exception.

  1. Vérifiez la version du servlet dans web.xml: <web-app version="2.5">

  2. Vérifiez si la version JSTL est prise en charge pour cette version de servlet: la version 2.5 du servlet utilise JSTL 1.2 ou la version 2.4 du servlet utilise JSTL 1.1

  3. Votre conteneur de servlet doit avoir la bibliothèque appropriée, ou vous devez l'inclure manuellement dans votre application. Par exemple: JSTL 1.2 nécessite jstl-1.2.jar

Que faire avec Tomcat 5 ou 6:

Vous devez inclure les fichiers jar appropriés dans votre répertoire WEB-INF / lib (cela ne fonctionnera que pour votre application) ou dans le tomcat / lib (fonctionnera globalement pour toutes les applications).

La dernière chose est un taglib dans vos fichiers jsp. Pour JSTL 1.2, la bonne est la suivante:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
— lukastymo
source
3
J'ai remarqué que cette question est assez populaire (beaucoup de téléspectateurs). C'est pourquoi j'avais décidé d'écrire un court tutoriel sur la façon de traiter ce problème
— lukastymo
17

J'ai trouvé une autre raison à ce type d'erreur: dans mon cas, quelqu'un a défini la propriété de conf/catalina.propertiesréglage tomcat.util.scan.StandardJarScanFilter.jarsToSkipsur *pour éviter les messages d'avertissement de journal, ignorant ainsi l'analyse nécessaire par Tomcat. Le retour à la valeur par défaut de Tomcat et l'ajout d'une liste appropriée de fichiers JAR à ignorer (sans inclure jstl-1.2 ou spring-webmvc) ont résolu le problème.

— resnbl
source
Oui!. Moi aussi. Quelqu'un (= moi-même) à un moment donné a mis tomcat.util.scan.StandardJarScanFilter.jarsToSkip=* en catalina.propertiesfichier dans une tentative (mal comprise?) D'accélérer le temps de démarrage de Tomcat. Arghh!
— peterh le
J'utilise le script suivant pour créer une liste jarsToSkip qui évite les TLD et les jars de fragments Web: pastebin.com/3Bfm1u6K
— Moreaki
1
Si vous ne souhaitez pas modifier votre jarsToSkipparamètre, en dessous se trouve un jarsToScanparamètre qui remplace tout élément dans jarsToSkip. Nous avons fini par ajouter taglibs*.jarà notre jarsToScancomme nos taglibs étaient taglibs-standard-impl-1.2.5.jaret taglibs-standard-spec-1.2.5.jar.
— jabe
1
C'est la réponse qui a fonctionné pour moi. Dans conf/catalina.properties, je suis passé tomcat.util.scan.StandardJarScanFilter.jarsToSkip=*.jarà tomcat.util.scan.StandardJarScanFilter.jarsToScan=jstl*.jaret cela l'a corrigé.
— Gary S.
15 
jstl-1.2.jar --> <%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
jstl-1.1.jar --> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core" %>

vérifiez également les fichiers jars de dépendances que vous avez ajoutés javax.servlet.jaret javax.servlet.jsp.jstl-1.2.1.jarou non dans votre dossier WEB-INF / lib. Dans mon cas, ces deux ont résolu le problème.

— streethawk
source
pouvez-vous s'il vous plaît jeter un oeil à la question ici [ stackoverflow.com/questions/44039706/…
— Kasun Siyambalapitiya
10

Ajoutez le jstl-1.2.jardans le tomcat/libdossier.

Avec cela, votre erreur de dépendance sera à nouveau corrigée.

— Hadi Rasouli
source
10
  1. Télécharger jstl-1.2.jar

  2. Ajoutez cette directive à votre page: <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

  3. Collez le fichier JAR dans votre dossier WEB-INF / lib. Cela devrait fonctionner. (Cela a fonctionné pour moi.)

— Prashant Ghimire
source
3

Je voulais juste ajouter le correctif que j'ai trouvé pour ce problème. Je ne sais pas pourquoi cela a fonctionné. J'avais la bonne version de jstl (1.2) et aussi la bonne version de servlet-api (2.5)

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

J'ai également eu la bonne adresse dans ma page comme suggéré dans ce fil, qui est 

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

Ce qui a résolu ce problème pour moi était de supprimer la balise scope de mon fichier xml dans le pom pour ma dépendance jstl 1.2. Encore une fois, je ne sais pas pourquoi cela a résolu le problème, mais juste au cas où quelqu'un ferait le printemps avec le tutoriel JPA et Hibernate sur pluralsight et aurait sa configuration pom de cette façon, essayez de supprimer la balise scope et voyez si cela le résout. Comme je l'ai dit, cela a fonctionné pour moi.

— gnattyp
source
2

J'avais complètement désactivé les outils MAVEN et Spring. Et j'ai dû ajouter les pots suivants pour que mon environnement fonctionne correctement.

  • spring-aop-4.0.3.RELEASE.jar
  • spring-beans-4.0.3.RELEASE.jar (difficile de trouver ce correctif, d'autres org.springframework <3.versions> ne fonctionnaient tout simplement pas.
  • spring-context-4.0.3.RELEASE.jar
  • spring-core-4.0.3.RELEASE.jar
  • expression-ressort-4.0.3.RELEASE.jar
  • spring-web-4.0.3.RELEASE.jar
  • spring-webmvc-4.0.3.RELEASE.jar
  • jstl-1.2.jar

Le pire de tout était jstl-api-1.2.jaret javax-servlet.jsp.jst-api-1.2.1.jar. Ils n'ont tout simplement pas fonctionné.

jstl-1.2.jar a bien fonctionné.

— Siddharth
source
1
+1 Après m'être cogné la tête contre le mur pendant des heures, utiliser jstl-1.2au lieu de jstl-1.2.1travailler pour moi aussi, et je ne sais pas pourquoi.
— evjak
1

Si vous utilisez Spring Boot, envisagez de supprimer server.tomcat.additional-tld-skip-patterns=*.jarde Application.propertiess'il y en a

— Askar
source
0

Toutes les réponses à cette question m'ont aidé mais j'ai pensé ajouter des informations supplémentaires pour la postérité.

Il s'est avéré que j'avais une dépendance de test sur gwt-test-utilslaquelle le gwt-devpackage était introduit . gwt-devContient malheureusement une copie complète de Jetty, JSP, JSTL, etc. qui était en avance sur les paquets appropriés sur le chemin de classe. Ainsi, même si j'avais des dépendances appropriées sur le JSTL 1.2, il chargerait la version 1.0 interne à gwt-dev. Plaindre.

La solution pour moi était de ne pas exécuter avec la portée de test, donc je ne récupère pas le gwt-test-utilspackage au moment de l'exécution. La suppression du gwt-devpackage du classpath d'une autre manière aurait également résolu le problème.

— gris
source
0

Juste eu un problème similaire dans Eclipse corrigé avec:

rightclick on project->Properties->Deployment Assembly->add Maven Dependencies

quelque chose l'a expulsé avant, pendant que je modifiais mon pom.xml

J'avais tous les fichiers jar nécessaires, l'URI taglib et web.xml était ok

— w3Charlie
source
0

Une réponse pour l'année 2020

La question est toujours très populaire, mais toutes les réponses sont sérieusement dépassées. Tous les composants Java EE ont été divisés en divers projets Jakarta et JSTL n'est pas différent. Voici donc les dépendances Maven correctes à ce jour:

<dependency>
    <groupId>jakarta.servlet.jsp.jstl</groupId>
    <artifactId>jakarta.servlet.jsp.jstl-api</artifactId>
    <version>1.2.7</version>
</dependency>
<dependency>
    <groupId>org.glassfish.web</groupId>
    <artifactId>jakarta.servlet.jsp.jstl</artifactId>
    <version>1.2.6</version>
</dependency>

Oui, les versions et les groupIds ne correspondent pas, mais c'est une bizarrerie de l'état actuel du projet .

— JohnEye
source
oui, mais cela ne résout pas mon problème mais fermez, avec tomcat10, vous avez besoin de deux libs * taglibs-standard-impl-1.2.5-migrated-0.0.1.jar * taglibs-standard-spec-1.2.5-migrated- 0.0.1.jar cette lib peut être récupéré à partir de l' échantillon de tomcat10 webapps DonT aussi balayage taglibs-standard * sous forme de fichiers tld est là - bas, cela peut être désactiver dans context.xml dans le répertoire lib webapp META-CONF
— JasonW
-1

Cela a fonctionné pour moi 

    <groupId>jstl</groupId>
    <artifactId>jstl</artifactId>
    <version>1.2</version>
— Ajay Kumar Sinha
source
-1

J'ai eu le même problème, j'utilise eclipse, juste au cas où d'autres rencontreraient le même problème:
dans eclipse, double-cliquez sur le serveur tomcat,
arrêtez le serveur
décochez la case "modules serveur sans publication",
démarrez le serveur.

entrez la description de l'image ici

— JavaSheriff
source
-2

Résolution d'un problème similaire dans IBM RAD 7.5 en sélectionnant:

  1. Propriétés des projets
  2. Facettes du projet
  3. Case à cocher JSTL
— c. hantzis
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.