¿Cómo instalar JSTL? La uri absoluta: http://java.sun.com/jstl/core no se puede resolver

134

No sé lo que hice incorrectamente, pero no puedo incluir JSTL. Tengo jstl-1.2.jar, pero desafortunadamente recibo una excepción:

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)

Yo tengo:

  • 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
fuente
44
Tuve que agregar la taglibs depdendency también al lado del jstl y simplemente funcionó.
— Christian Vielma

Respuestas:

193

org.apache.jasper.JasperException: la uri absoluta: http://java.sun.com/jstl/core no se puede resolver en web.xml o en los archivos jar implementados con esta aplicación

Ese URI es para JSTL 1.0, pero en realidad está usando JSTL 1.2 que usa URI con una /jspruta adicional (porque JSTL, quien inventó las expresiones EL, estaba integrado desde la versión 1.1 como parte de JSP para compartir / reutilizar la lógica EL en JSP simple también).

Por lo tanto, arregle el URI de taglib de acuerdo con la documentación de JSTL :

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

Además, debe asegurarse absolutamente de que no arroja varios archivos JSTL JAR con versiones diferentes al classpath en tiempo de ejecución. Este es un error bastante común entre los usuarios de Tomcat. El problema con Tomcat es que no ofrece JSTL de fábrica y, por lo tanto, debe instalarlo manualmente. Esto no es necesario en servidores Java EE normales. Consulte también ¿Qué es exactamente Java EE?

En su caso específico, su pom.xml básicamente le dice que tiene jstl-1.2.jar y standard-1.1.2.jar juntos. Esto está mal. Básicamente, estás mezclando JSTL 1.2 API + impl de Oracle con JSTL 1.1 impl de Apache. Necesitas eliminar cualquiera standard-xxx.jar. Sólo solamente el jstl-1.2.jares suficiente.

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

Los usuarios que no son de Maven pueden lograr lo mismo al soltar el archivo físico jstl-1.2.jar en la /WEB-INF/libcarpeta del proyecto de la aplicación web (¡ absolutamente no suelte standard.jar ni ningún archivo .tld suelto allí!). Eliminarlos si es necesario.

En caso de que esté utilizando un servidor Java EE normal como WildFly, Payara, etc., en lugar de un contenedor de servlet básico como Tomcat, Jetty, etc., no necesita instalar JSTL explícitamente. Los servidores Java EE normales ya proporcionan JSTL de fábrica. En otras palabras, no necesita agregar JSTL pom.xmlni eliminar ningún archivo JAR / TLD en la aplicación web. Solamente la providedcoordenada Java EE con ámbito es suficiente:

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

Además, también debe asegurarse de que su web.xmldeclaración sea conforme al menos Servlet 2.4 y, por lo tanto, no como Servlet 2.3 o anterior. De lo contrario, las expresiones EL dentro de las etiquetas JSTL no funcionarían. Elija la versión más alta que coincida con su contenedor de destino y asegúrese de que no tiene una <!DOCTYPE>en su lugar web.xml. Aquí hay un ejemplo compatible con 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>

Ver también:

— BalusC
fuente
He cambiado a / jsp y: org.apache.jasper.JasperException: la uri absoluta: java.sun.com/jsp/jstl/core no se puede resolver en web.xml ....
— lukastymo
44
Entonces tu classpath es un desastre. Limpiarlo. No sé qué está haciendo Maven y si es inteligente, pero para JSTL 1.2 no necesitas el standardtaglib. Lea la página de información de la etiqueta para más detalles.
— BalusC
44
Me gusta mucho la página wiki de JSTL que juntaste. Sin embargo, dado que esta pregunta es el principal éxito de Google para el mensaje de error en particular, me tomo la libertad de editarla y observar que el URI "no jsp" es de JSTL 1.0.
— kdgregory
2
@kdgregory: Gracias :)
— BalusC
1
si está utilizando Gradle, agregue esta dependencia:compile('javax.servlet:jstl:1.2')
— benscabbia
36

@BalusC tiene toda la razón, pero si aún encuentra esta excepción, significa que algo ha hecho mal. La información más importante que encontrará se encuentra en la página de información de la etiqueta SO JSTL .

Básicamente, este es un resumen de lo que debe hacer para lidiar con esta excepción.

  1. Verifique la versión del servlet en web.xml: <web-app version="2.5">

  2. Compruebe si la versión JSTL es compatible con esta versión de servlet: la versión 2.5 del Servlet usa JSTL 1.2 o la versión 2.4 del Servlet usa JSTL 1.1

  3. Su contenedor de servlet debe tener la biblioteca apropiada, o debe incluirlo manualmente en su aplicación. Por ejemplo: JSTL 1.2 requiere jstl-1.2.jar

Qué hacer con Tomcat 5 o 6:

Debe incluir los jar apropiados en su directorio WEB-INF / lib (funcionará solo para su aplicación) o en tomcat / lib (funcionará globalmente para todas las aplicaciones).

Lo último es un taglib en sus archivos jsp. Para JSTL 1.2, la correcta es esta:

<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
— lukastymo
fuente
3
Me di cuenta de que esta pregunta es bastante popular (muchos espectadores). Por eso decidí escribir un breve tutorial sobre cómo solucionar este problema
— Lukastymo
17

Encontré otra razón para este tipo de error: en mi caso, alguien configuró la propiedad de conf/catalina.propertiesconfiguración para evitar mensajes de advertencia de registro, omitiendo así el escaneo necesario de Tomcat. Cambiar esto al valor predeterminado de Tomcat y agregar una lista apropiada de jarras para omitir (sin incluir jstl-1.2 o spring-webmvc) resolvió el problema.tomcat.util.scan.StandardJarScanFilter.jarsToSkip*

— resnbl
fuente
¡Si!. Yo también. Alguien (= yo) en algún momento de poner tomcat.util.scan.StandardJarScanFilter.jarsToSkip=* en catalina.propertiesarchivo en un (mal entendido?) Intento de acelerar el tiempo de inicio de Tomcat. Arghh!
— Peter
Utilizo el siguiente script para crear una lista de jarsToSkip que evita los TLD y los frascos de fragmentos web: pastebin.com/3Bfm1u6K
— Moreaki
1
Si no desea cambiar su jarsToSkipconfiguración, debajo hay una jarsToScanconfiguración que anula cualquier cosa jarsToSkip. Terminamos agregando taglibs*.jara nuestro jarsToScancomo nuestros taglibs eran taglibs-standard-impl-1.2.5.jary taglibs-standard-spec-1.2.5.jar.
— jabe
1
Esta es la respuesta que funcionó para mí. En conf/catalina.properties, cambié tomcat.util.scan.StandardJarScanFilter.jarsToSkip=*.jara tomcat.util.scan.StandardJarScanFilter.jarsToScan=jstl*.jary eso lo arregló.
— 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" %>

También compruebe los frascos de dependencia que ha agregado javax.servlet.jary javax.servlet.jsp.jstl-1.2.1.jaro no en su WEB-INF / lib carpeta. En mi caso, estos dos resolvieron el problema.

— streethawk
fuente
¿Puedes echar un vistazo a la pregunta aquí [ stackoverflow.com/questions/44039706/…
— Kasun Siyambalapitiya
10

Agregue el jstl-1.2.jaren la tomcat/libcarpeta.

Con esto, su error de dependencia se reparará nuevamente.

— Hadi Rasouli
fuente
10
  1. Descargar jstl-1.2.jar

  2. Agregue esta directiva a su página: <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

  3. Pegue el archivo JAR en su carpeta WEB-INF / lib. Esto debería funcionar. (Funcionó para mí)

— Prashant Ghimire
fuente
3

Solo quería agregar la solución que encontré para este problema. No estoy seguro de por qué esto funcionó. Tenía la versión correcta de jstl (1.2) y también la versión correcta 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>

También tenía la dirección correcta en mi página como se sugiere en este hilo, que es 

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

Lo que solucionó este problema para mí fue eliminar la etiqueta de alcance de mi archivo xml en el pom para mi dependencia de jstl 1.2. Nuevamente, no estoy seguro de por qué eso lo solucionó, pero en caso de que alguien esté haciendo la primavera con el tutorial JPA e Hibernate en pluralsight y tenga su configuración pom de esta manera, intente eliminar la etiqueta de alcance y vea si eso lo soluciona. Como dije, funcionó para mí.

— gnattyp
fuente
2

Había desactivado completamente las herramientas MAVEN y Spring. Y tuve que agregar los siguientes jar para hacer que mi entorno funcione correctamente.

  • spring-aop-4.0.3.RELEASE.jar
  • spring-beans-4.0.3.RELEASE.jar (difícil de encontrar esta solución, otras org.springframework <3.versiones> simplemente no funcionaron.
  • 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

Lo peor de todo fue jstl-api-1.2.jary javax-servlet.jsp.jst-api-1.2.1.jar. Simplemente no funcionaron.

jstl-1.2.jar funcionado bien.

— Siddharth
fuente
1
+1 Después de golpearme la cabeza contra la pared durante horas, usar en jstl-1.2lugar de jstl-1.2.1trabajar también para mí, y no tengo idea de por qué.
— avojak
1

Si usa Spring boot, considere eliminar server.tomcat.additional-tld-skip-patterns=*.jarde Application.propertiessi hay alguna

— Askar
fuente
0

Todas las respuestas en esta pregunta me ayudaron, pero pensé que agregaría información adicional para la posteridad.

Resultó que tenía una dependencia de prueba en la gwt-test-utilsque traía el gwt-devpaquete. Lamentablemente gwt-devcontiene una copia completa de Jetty, JSP, JSTL, etc., que estaba por delante de los paquetes adecuados en el classpath. Entonces, aunque tenía dependencias adecuadas en el JSTL 1.2, cargaría la versión 1.0 interna gwt-dev. Queja.

La solución para mí fue no ejecutar con el alcance de la prueba para no recoger el gwt-test-utilspaquete en tiempo de ejecución. Eliminar el gwt-devpaquete del classpath de alguna otra manera también habría solucionado el problema.

— gris
fuente
0

Acabo de tener un problema similar en Eclipse solucionado con:

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

algo lo echó antes, mientras estaba editando mi pom.xml

Tenía todos los archivos jar necesarios, taglib uri y web.xml estaban bien

— w3Charlie
fuente
0

Una respuesta para el año 2020

La pregunta sigue siendo muy popular, pero todas las respuestas están muy desactualizadas. Todos los componentes de Java EE se dividieron en varios proyectos de Yakarta y JSTL no es diferente. Así que aquí están las dependencias correctas de Maven a partir de hoy:

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

Sí, las versiones y los ID de grupo no coinciden, pero esa es una peculiaridad del estado actual del proyecto .

— JohnEye
fuente
sí, pero esto no resuelve mi problema pero está cerca, con tomcat10, necesita dos libs * taglibs-standard-impl-1.2.5-migrated-0.0.1.jar * taglibs-standard-spec-1.2.5-migrated- 0.0.1.jar esta lib se puede recuperar de tomcat10 sample webapps tampoco escanea taglibs-standard * ya que los archivos tld están allí, esto se puede deshabilitar en context.xml en la lib de la
— webapp
-1

Esto funcionó para mí 

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

Tuve el mismo problema, estoy usando eclipse, en caso de que otros experimenten el mismo problema:
en eclipse, haga doble clic en el servidor Tomcat,
detenga el servidor,
desmarque los "módulos de servidor sin publicar" para
iniciar el servidor.

ingrese la descripción de la imagen aquí

— JavaSheriff
fuente
-2

Se resolvió un problema similar en IBM RAD 7.5 seleccionando:

  1. Proyectos de propiedades
  2. Facetas del proyecto
  3. Casilla de verificación JSTL
— C. hantzis
fuente
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.