Solución:
org.apache.jasper.JasperException: el uri absoluto: http://java.sun.com/jstl/core no se puede resolver ni en web.xml ni 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 un adicional /jsp ruta (porque JSTL, que inventó las expresiones EL, se integró 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, corrija el URI de taglib según corresponda según la documentación de JSTL:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
Además necesitas hacer absolutamente seguro que no arroje varios archivos JAR JSTL con versiones diferentes juntos en la ruta de clases de 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 listo para usar y, por lo tanto, debe instalarlo manualmente. Esto no es necesario en los servidores normales de Jakarta EE. 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á mezclando JSTL 1.2 API + impl de Oracle con JSTL 1.1 impl de Apache. Debe ceñirse a una sola implementación de JSTL.
Instalación de JSTL en Tomcat 10+
En caso de que ya esté en Tomcat 10 o más reciente (la primera versión Jakartified, con jakarta.* paquete en lugar de javax.* paquete), utilice JSTL 2.0 a través de este único dependencia:
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jakarta.servlet.jsp.jstl</artifactId>
<version>2.0.0</version>
</dependency>
Los usuarios que no son de Maven pueden lograr lo mismo colocando los siguientes dos archivos físicos en /WEB-INF/lib carpeta del proyecto de la aplicación web (hacer absolutamente no coloque * .jar estándar o cualquier archivo .tld suelto allí. retírelos si es necesario).
- jakarta.servlet.jsp.jstl-2.0.0.jar (esta es la implícita JSTL 2.0 de EE4J)
- jakarta.servlet.jsp.jstl-api-2.0.0.jar (esta es la API JSTL 2.0)
Instalación de JSTL en Tomcat 9-
En caso de que aún no esté en Tomcat 10, pero todavía en Tomcat 9 o anterior, use JSTL 1.2 a través de este único dependencia:
<dependency>
<groupId>org.glassfish.web</groupId>
<artifactId>jakarta.servlet.jsp.jstl</artifactId>
<version>1.2.6</version>
</dependency>
Los usuarios que no son de Maven pueden lograr lo mismo colocando los siguientes dos archivos físicos en /WEB-INF/lib carpeta del proyecto de la aplicación web (hacer absolutamente no coloque * .jar estándar o cualquier archivo .tld suelto allí. retírelos si es necesario).
- jakarta.servlet.jsp.jstl-1.2.6.jar (este es el JSTL 1.2 impl de EE4J)
- jakarta.servlet.jsp.jstl-api-1.2.7.jar (esta es la API JSTL 1.2)
Instalación de JSTL en un servidor JEE normal
En caso de que esté utilizando un servidor Jakarta EE normal como WildFly, Payara, etc. en lugar de un contenedor de servlets básico como Tomcat, Jetty, etc., entonces no necesita instalar explícitamente JSTL en absoluto. Servidores normales de Jakarta EE ya proporcione JSTL de fábrica. En otras palabras, no es necesario agregar JSTL a pom.xml ni eliminar archivos JAR / TLD en la aplicación web. Únicamente el provided La coordenada EE de Yakarta con alcance es suficiente:
<dependency>
<groupId>jakarta.platform</groupId>
<artifactId>jakarta.jakartaee-api</artifactId>
<version><!-- 9.0.0, 8.0.0, etc depending on your server --></version>
<scope>provided</scope>
</dependency>
Asegúrese de que la versión web.xml sea la correcta
Además, también debe asegurarse de que su web.xml se declara conforme por lo 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, a su vez, no funcionarían. Elija la versión más alta que coincida con su contenedor de destino y asegúrese de que no tiene un <!DOCTYPE> en cualquier lugar de tu web.xml. Aquí hay un ejemplo compatible con Servlet 5.0 (Tomcat 10):
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns="https://jakarta.ee/xml/ns/jakartaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="https://jakarta.ee/xml/ns/jakartaee https://jakarta.ee/xml/ns/jakartaee/web-app_5_0.xsd"
version="5.0">
<!-- Config here. -->
</web-app>
Y 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:
- Documentación de JSTL core taglib (para los URI de taglib correctos)
-
Expresiones EL no evaluadas en JSP
- Cómo configurar pom.xml para Tomcat 10+ o Tomcat 9-
@BalusC tiene toda la razón, pero si aún encuentra esta excepción, significa que ha hecho algo mal. La información más importante que encontrará se encuentra en la página de información de etiquetas de SO JSTL.
Básicamente, este es un resumen de lo que debe hacer para hacer frente a esta excepción.
-
Verifique la versión del servlet en web.xml:
<web-app version="2.5"> -
Compruebe si la versión de JSTL es compatible con esta versión de servlet: versión de servlet 2.5 usa JSTL 1.2 o versión de Servlet 2.4 utiliza JSTL 1.1
-
Su contenedor de servlets debe tener la biblioteca adecuada o debe incluirla manualmente en su aplicación. Por ejemplo: JSTL 1.2 requiere jstl-1.2.jar
Qué hacer con Tomcat 5 o 6:
Debe incluir jar (s) 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, el correcto es este:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
Encontré otra razón para este tipo de error: en mi caso, alguien configuró el conf/catalina.properties configuración tomcat.util.scan.StandardJarScanFilter.jarsToSkip propiedad a * para evitar los mensajes de advertencia de registro, omitiendo así el análisis necesario de Tomcat. Cambiar esto de nuevo al valor predeterminado de Tomcat y agregar una lista apropiada de archivos jar para omitir (sin incluir jstl-1.2 o spring-webmvc) resolvió el problema.