web-dev-qa-db-fra.com

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

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, j'ai 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>
jspservletsjstl
111
smas

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

Cet URI est pour JSTL 1.0, mais vous utilisez JSTL 1.2 qui utilise des URI avec un chemin supplémentaire /jsp (car JSTL, qui a inventé les expressions EL, a été intégré à JSP depuis la version 1.1 afin de partager/réutiliser la logique EL en clair aussi JSP).

Donc, corrigez l'URI de taglib en conséquence:

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

De plus, votre POM spécifie également l'implémentation d'Apache JSTL 1.1 via taglibs:standard. Ceci est inutile et même dangereux lorsque vous avez déjà JSTL 1.2 API + impl fourni via javax.servlet:jstl , car 1.1 et 1.2 seront évidemment en conflit. Seule seulement la dépendance JSTL 1.2 suivante devrait le faire pour que JSTL soit installé dans votre application Web ciblée par Tomcat (ne pas définissez le <scope> sur provided car Tomcat ne le fournit pas à la livraison! ):

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

Les utilisateurs non-Maven peuvent obtenir le même résultat en déposant le fichier unique jstl-1.2.jar dans le dossier /WEB-INF/lib du projet d’application Web (ne pas supprimez le fichier standard.jar ou tout fichier .tld lâche!! ).

Si vous utilisez réellement un serveur Java EE normal tel que WildFly, Payara, etc. au lieu d'un conteneur servlet barebones tel que Tomcat, Jetty, etc., vous n'avez pas besoin d'installer explicitement JSTL. Les serveurs Java EE normaux fournissent déjà JSTL prêt à l'emploi. En d'autres termes, vous n'avez pas besoin d'ajouter JSTL à pom.xml ni de supprimer des fichiers JAR/TLD dans webapp. Seule la coordonnée Java EE provided é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.xml est déclaré conforme au moins} _ Servlet 2.4 et donc pas comme Servlet 2.3 ou plus ancien. Sinon, les expressions EL contenues dans les balises JSTL ne fonctionneraient pas. Choisissez la version la plus élevée correspondant à votre conteneur cible et assurez-vous de ne pas avoir de <!DOCTYPE> nulle part dans votre web.xml. Voici un exemple compatible avec 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:

159
BalusC

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

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

  1. Vérifiez la version du servlet dans le fichier 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 du servlet 2.5 utilise JSTL 1.2 ou la version du servlet 2.4 utilise JSTL 1.1

  3. Votre conteneur de servlets 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 le ou les fichiers JAR appropriés dans votre répertoire WEB-INF/lib (cela ne fonctionnera que pour votre application) ou dans Tomcat/lib (fonctionnera globalement pour toutes les applications).

La dernière chose est un taglib dans vos fichiers jsp. Pour JSTL 1.2, le correct est le suivant:

<%@ taglib prefix="c" uri="http://Java.Sun.com/jsp/jstl/core" %>
34
smas
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" %>

veuillez également vérifier les jars de dépendance que vous avez ajoutés javax.servlet.jar et javax.servlet.jsp.jstl-1.2.1.jar ou non dans votre dossier WEB-INF/lib. Dans mon cas, ces deux problèmes ont résolu le problème.

13
streethawk

J'ai trouvé une autre raison à ce type d'erreur: dans mon cas, quelqu'un a défini la propriété Tomcat.util.scan.StandardJarScanFilter.jarsToSkip de catalina.properties sur * pour éviter les messages d'avertissement du journal, ignorant ainsi l'analyse nécessaire par Tomcat. Remettre cette valeur à Tomcat par défaut et ajouter une liste appropriée de fichiers jar à ignorer (à l'exclusion de jstl-1.2 ou de spring-webmvc) ont résolu le problème.

10
resnbl
  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 marcher. (Cela a fonctionné pour moi.)

8
Prashant Ghimire

Ajoutez le jstl-1.2.jar dans le dossier Tomcat/lib.

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

6
Hadi Rasouli

J'ai mentionné que la dépendance Maven dans le fichier pom.xml était fausse. CA devrait etre

    <dependency>
        <groupId>jstl</groupId>
        <artifactId>jstl</artifactId>
        <version>1.2</version>
    </dependency>
3
LoBo

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

  • spring-aop-4.0.3.RELEASE.jar
  • spring-beans-4.0.3.RELEASE.jar (difficile à trouver, d'autres org.springframework <3.versions> ne fonctionnent tout simplement pas.
  • spring-context-4.0.3.RELEASE.jar
  • spring-core-4.0.3.RELEASE.jar
  • spring-expression-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 tous était jstl-api-1.2.jar et javax-servlet.jsp.jst-api-1.2.1.jar. Ils ont juste n'ont pas travaillent. 

`jstl-1.2.jar a bien fonctionné.

2
Siddharth

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, c’était de supprimer la balise scope de mon fichier xml dans le pom de ma dépendance jstl 1.2. Encore une fois, vous ne savez pas pourquoi cela a résolu le problème, mais juste au cas où quelqu'un utiliserait JPA et le tutoriel Hibernate sur pluralsight et que sa configuration de pom serait configurée de cette façon, essayez de supprimer la balise scope et voyez si cela résout le problème. Comme je l'ai dit, cela a fonctionné pour moi. 

2
gnattyp

Si vous utilisez un démarrage à ressort, envisagez de supprimer server.Tomcat.additional-tld-skip-patterns=*.jar de Application.properties s’il en existe

0
Askar

Je viens d'avoir un problème similaire dans Eclipse Résolu avec:

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

quelque chose a jeté avant, pendant que je montais mon pom.xml

J'avais besoin de tous les fichiers jar, taglib uri et web.xml était ok

0
w3Charlie

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

Il s'est avéré que j'avais une dépendance de test sur gwt-test-utils qui a amené le paquet gwt-dev. Malheureusement, gwt-dev contient une copie complète de Jetty, JSP, JSTL, etc. qui était en avance sur les packages appropriés sur le classpath. Donc, même si j'avais des dépendances appropriées sur le JSTL 1.2, cela chargerait la version interne 1.0 dans gwt-dev. Plaindre.

La solution pour moi était de ne pas exécuter avec la portée du test afin que je ne récupère pas le paquet gwt-test-utils au moment de l'exécution. Supprimer le package gwt-dev du classpath d'une autre manière aurait également résolu le problème.

0
Gray