web-dev-qa-db-fra.com

Tomcat 7 et JSTL

J'ai écrit une application Web avec Eclipse Tomcat et cela fonctionne sur mon Tomcat 7 local, lorsque j'ai essayé de la publier en ligne sur un Tomcat 7, j'ai eu l'erreur suivante:

GRAVE: Servlet.service () pour le servlet [obliquid.servlet.Index] dans le contexte avec le chemin [/ cp] a levé une exception [L'URI absolu: http://Java.Sun.com/jsp/jstl/core ne peut pas être résolu dans le fichier web.xml ou les fichiers jar déployés avec cette application]

Tomcat 7 a "versions Spec: Servlet 3.0, JSP 2.2, EL 2.2", donc JSTL n'est pas inclus?

Lorsque j'ai essayé de télécharger standard.jar et jstl.jar, j'ai eu l'erreur suivante:

org.Apache.jasper.JasperException: /jsp/index.jsp (ligne: 3, colonne: 62) Impossible de lire le TLD "META-INF/c.tld" du fichier JAR "jndi:/localhost/cp/WEB-INF /lib/standard.jar ": org.Apache.jasper.JasperException: impossible de charger ou d'instancier la classe TagLibraryValidator: org.Apache.taglibs.standard.tlv.JstlCoreTLV

J'ai fait une recherche sur Google, mais je n'ai pas pu le trier, certains ont dit que cela pourrait être causé par des versions conflictuelles des pots. Peut-être que je ne devrais pas inclure ces pots et utiliser une autre URL JSTL? Le mien est pour JSTL 1.1 Je pense, y a-t-il une nouvelle URL pour JSTL 1.2?

Que dois-je faire pour résoudre le problème et faire fonctionner cette application?

javatomcatjstltomcat7
44
stivlo

Tomcat n'a jamais inclus JSTL.

Vous devez mettre le jstl et les pots standard dans WEB-INF/lib (vous l'avez fait) et assurez-vous que vous avez les autorisations pour les lire (chmod)

Votre URI est correct et devrait fonctionner (fonctionne ici)

45
Bozho

Je me bats avec ça depuis plusieurs heures. Voici une solution complète.

  1. J'utilise Tomcat 7, qui est un serveur compatible Servlet 3.0.

  2. Si vous souhaitez utiliser la spécification Servlet 3.0, vous devez avoir votre web.xml comme suit:

    <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_3_0.xsd" version="3.0">

  3. Si vous utilisez Maven, votre pom.xml devrait avoir ces lignes.

    <dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>javax.servlet-api</artifactId>
    <version>3.0.1</version>
    <scope>provided</scope>
</dependency>

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

<dependency>
    <groupId>org.glassfish.web</groupId>
    <artifactId>jstl-impl</artifactId>
    <version>1.2</version>
    <exclusions>
        <exclusion>
            <artifactId>servlet-api</artifactId>
            <groupId>javax.servlet</groupId>
        </exclusion>
        <exclusion>
            <artifactId>jsp-api</artifactId>
            <groupId>javax.servlet.jsp</groupId>
        </exclusion>
        <exclusion>
            <artifactId>jstl-api</artifactId>
            <groupId>javax.servlet.jsp.jstl</groupId>
        </exclusion>
    </exclusions>
</dependency>

    Ces dépendances sont très importantes. JSTL 2.1 + Tomcat 7 + Servlet 3.0 est très cassé à moins que vous ne le répariez en utilisant ces lignes, en particulier la partie d'exclusion. Ce qui se passe, c'est que les pots JSTL 2.1 récupèrent en fait les mauvaises versions de la spécification Servlet - 2.5. À moins que vous ne l'empêchiez de se produire, vous serez dans tout un monde de douleur. Un merci spécial à M. Murray Todd Williams pour ces idées .

  4. Enfin, au cas où Maven ne trouverait pas ces JARS, vous pouvez rendre Eclipse heureux en incluant trois JARS avec votre projet et en faisant le projet habituel -> Propriétés -> Java Build Path et incluez de cette façon - bien que Maven devrait en prendre soin.

    javax.servlet-api-3.0.1.jar
javax.servlet.jsp.jstl-1.2.1.jar
javax.servlet.jsp.jstl-api-1.2.1.jar

  5. Notez s'il vous plaît! Cette configuration exacte ne s'applique que si vous utilisez la combinaison magique de:

    1. Un serveur d'applications compatible Servlet 3.0 tel que Tomcat 7

    2. Votre web.xml a le bon espace de noms pour la spécification Servlet 3.0

    3. Vous avez ces trois JARS et aucun autre JSTL ou Servlet JARS sur votre chemin de classe.

  6. Assurez-vous que vous ne placez pas de copies de ces fichiers JAR dans votre répertoire WEB-INF/lib car ils seraient dans ce cas envoyés au serveur, provoquant ainsi LinkageErrors.

  7. Dans votre JSP, vous devez avoir cette ligne PRECISE, formatée exactement comme je l'ai ou sinon Eclipse se plaindra de ne pas reconnaître les balises c: blah:

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

  8. Quel PITA suspendu! C'est BEAUCOUP plus difficile à implémenter que toute autre version de JSTL. C'est le seul exemple de quelque chose qui devient beaucoup plus compliqué plutôt que plus simple dans les itérations ultérieures.

54
Tom Hunter

Votre uri est correct pour JSTL 1.2. Vous devez faire deux choses:

Change ton web.xml pour utiliser la dernière version de l'application Web.

Il devrait ressembler à ceci ou à une version ultérieure;

<?xml version="1.0" encoding="UTF-8"?>
<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_3_0.xsd" 
    version="3.0">

Ensuite, mettez la version correcte des jars jstl dans votre code. Pour 1.2 Vous pouvez les télécharger ici .

Cela devrait vous donner deux pots:

  • jstl-api.jar
  • jstl-impl.jar

Utilisez-les au lieu de standard.jar et jstl.jar qui étaient pour la version précédente.

Faites-nous savoir comment cela fonctionne pour vous.

14
VikC

Pour une exécution sur Apache Tomcat 7, il est probablement approprié de les ajouter à votre POM. Ces bocaux ne font pas référence aux bocaux javax.servlet comme le font les glassfish, donc il n'y a pas besoin d'exclusions.

<dependency>
    <groupId>org.Apache.taglibs</groupId>
    <artifactId>taglibs-standard-spec</artifactId>
    <version>1.2.1</version>
</dependency>
<dependency>
    <groupId>org.Apache.taglibs</groupId>
    <artifactId>taglibs-standard-impl</artifactId>
    <version>1.2.1</version>
</dependency>
5
K.Nicholas

Pour Tomcat, il existe une solution de dépendance plus simple pour JSTL 1.1.2:

<dependency>
    <groupId>javax.servlet</groupId>
    <artifactId>jstl</artifactId>
    <!-- Apache Taglibs does not implement version 1.2 -->
    <version>1.1.2</version>
  </dependency>
  <dependency>
    <groupId>taglibs</groupId>
    <artifactId>standard</artifactId>
    <version>1.1.2</version>
    </dependency>
  <dependency>
    <groupId>taglibs</groupId>
    <artifactId>c</artifactId>
    <version>1.1.2</version>
    <type>tld</type>
  </dependency>
  <dependency>
    <groupId>taglibs</groupId>
    <artifactId>fmt</artifactId>
    <version>1.1.2</version>
    <type>tld</type>
  </dependency>
<dependency>

Voir ici pour plus de détails (blog personnel).

REM: Plus de détails comme demandé, il faut inclure les dépendances JSTL pour les rendre disponibles sur Tomcat. Pourtant, la version 1.2 n'est pas vraiment nécessaire, puisque la version 1.1.2 (fournie par Apache, comme Tomcat) fait aussi le travail. Sa seule exigence est Servlet 2.4 et JSP 2.2, et l'OP mentionne Servlet 3.0 et JSP 2.0, ce qui est assez bon.

0
Jérôme Verstrynge

Il y a deux réponses ici qui sont généralement correctes en ce qui concerne la façon de résoudre ce problème lors de l'utilisation de Maven pour résoudre ce problème. Cependant, les deux ne sont pas complets à 100%.

Utilisation des exclusions par @ réponse de Tom Hunter

Cette réponse fonctionne. Cependant, il y aura toujours des messages de journal de Tomcat concernant les définitions de TLD en double. Cela est dû au fait que les artefacts jstl et jstl-impl incluent les définitions TLD. Pour supprimer ces messages, je pense qu'une meilleure configuration Maven est la suivante:

<dependency>
    <version>1.2</version>
    <scope>runtime</scope>
    <groupId>javax.servlet.jsp.jstl</groupId>
    <artifactId>jstl-api</artifactId>
    <exclusions>
        <exclusion>
            <artifactId>servlet-api</artifactId>
            <groupId>javax.servlet</groupId>
        </exclusion>
        <exclusion>
            <artifactId>jsp-api</artifactId>
            <groupId>javax.servlet.jsp</groupId>
        </exclusion>
    </exclusions>
</dependency>

<dependency>
    <groupId>org.glassfish.web</groupId>
    <artifactId>jstl-impl</artifactId>
    <version>1.2</version>
    <scope>runtime</scope>
    <exclusions>
        <exclusion>
            <artifactId>servlet-api</artifactId>
            <groupId>javax.servlet</groupId>
        </exclusion>
        <exclusion>
            <artifactId>jsp-api</artifactId>
            <groupId>javax.servlet.jsp</groupId>
        </exclusion>
        <exclusion>
            <artifactId>jstl-api</artifactId>
            <groupId>javax.servlet.jsp.jstl</groupId>
        </exclusion>
    </exclusions>
</dependency>

Cela inclut uniquement les classes api jstl avec les exclusions nécessaires pour éviter les problèmes expliqués dans le reste de cette réponse.

Utilisation de nouvelles versions de POM par @ réponse de George

Il m'a fallu un certain temps pour le réaliser, mais il existe de nouvelles versions des pom JSTL disponibles. C'est vraiment déroutant car ces nouveaux packages utilisent des conventions de dénomination similaires, mais légèrement différentes. Ces versions plus récentes marquent les dépendances javax.servlet, javax.jsp, etc. comme l'étendue fournie afin qu'elles n'aient pas besoin d'être exclues. La version 1.2.1 dépend d'une version 1.2.1 de jstl-api. Et donc cela serait fonctionne aussi bien que la réponse ci-dessus:

<dependency>
    <groupId>org.glassfish.web</groupId>
    <artifactId>javax.servlet.jsp.jstl</artifactId>
    <version>1.2.1</version>
    <scope>runtime</scope>
</dependency>

Cela diffère légèrement de la réponse de George car j'ai changé la portée en runtime. George a précisé la portée telle que fournie. Avec une portée fournie, les fichiers jar devraient être copiés manuellement dans le répertoire lib Tomcat, ou une autre dépendance devrait inclure l'implémentation nécessaire.

Cependant, Je n'ai pas pu trouver la version 1.2.1 de l'impl dans maven central, jboss repo ou tout autre autres repos. J'ai fini par tourner en rond et j'ai finalement utilisé un dépôt basé sur un fichier local pour stocker le pot. La dépendance et le bocal sont décrits ici:

0
kaliatech

Rien de tout cela ne fonctionnait pour moi, j'ai simplement créé le projet sans utiliser Maven et ajouter directement les fichiers JAR.

0
CommonCoreTawan