Keywords: JSTL | Tomcat | URI resolution error
Abstract: This paper provides a comprehensive analysis of the common error 'The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved' encountered when using JSTL in Apache Tomcat 7 environments. By examining root causes, version compatibility issues, and configuration details, it offers a complete solution based on JSTL 1.2, supplemented with practical tips on Maven configuration and Tomcat scanning filters, helping developers resolve such deployment problems thoroughly.
Problem Background and Error Analysis
In Java Web development, JSTL (JavaServer Pages Standard Tag Library) is widely used in JSP pages to simplify logic processing. However, developers often encounter a classic error during deployment: org.apache.jasper.JasperException: The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this application. This error typically occurs in environments with Apache Tomcat 7 or higher, combined with JDK 1.7 or later, when attempting to use the JSTL core tag library in JSP pages. The stack trace indicates that the issue stems from Tomcat's Jasper compiler failing to locate the corresponding Tag Library Descriptor (TLD) in web.xml or the deployed jar files, leading to URI resolution failure.
Core Causes: JSTL Version Incompatibility and Jar File Conflicts
Based on the best answer analysis, the primary root of this error lies in the混乱 use of JSTL library versions. A common mistake is placing both jstl-1.2.jar and standard.jar in the WEB-INF/lib directory. In reality, standard.jar is a legacy library from the JSTL 1.0 era, with a TLD URI of http://java.sun.com/jstl/core (without the /jsp path), whereas JSTL 1.2 uses the updated URI http://java.sun.com/jsp/jstl/core. When both coexist, Tomcat may prioritize loading the older jar, causing URI mismatch and throwing the resolution error. Additionally, improper jar placement or Tomcat configuration issues can exacerbate this situation.
Solution: Standardized Deployment Based on JSTL 1.2
To彻底 resolve this issue, it is recommended to follow these steps, ensuring environment configuration aligns with JSTL 1.2 standards:
- Remove Conflicting Jar Files: First, delete
standard.jarfrom theWEB-INF/libdirectory, as it is incompatible with JSTL 1.2 and unnecessary. Retain onlyjstl-1.2.jar, which can be downloaded from Maven Central (e.g., jstl-1.2.jar) or obtained via build tools. - Verify JSP Page Configuration: At the top of JSP pages, ensure the correct taglib directive is used, e.g.,
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>. This URI corresponds to the JSTL 1.2 core library, avoiding older URIs. - Check Tomcat Deployment: Restart the Tomcat server to ensure jar files are loaded correctly. This can be verified by checking Tomcat logs or using tools like
jar -tf jstl-1.2.jarto confirm TLD file presence.
In the example code, the developer uses the <c:forEach> tag to iterate over Bean properties, which should work fine under JSTL 1.2 if jar configuration is correct. For example:
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<c:forEach var="item" items="${listdomain.status}">
<option><c:out value="${item}" /></option>
</c:forEach>
Supplementary References: Maven Configuration and Tomcat Optimization
Other answers provide additional insights that can serve as supplements:
- Maven Project Configuration: If using Maven, add the JSTL dependency in
pom.xmland set the scope to provided, ensuring the jar is supplied by the container (e.g., Tomcat) to avoid version conflicts. Example configuration:
Note that the groupId may vary based on the library source; it is advisable to use standard coordinates.<dependency> <groupId>javax.servlet</groupId> <artifactId>jstl</artifactId> <version>1.2</version> <scope>provided</scope> </dependency> - Tomcat Scanning Filters: Check Tomcat's
catalina.propertiesfile to ensure that not all jar files are skipped intomcat.util.scan.StandardJarScanFilter.jarsToSkip, as this might prevent TLD scanning. Proper configuration can optimize performance and avoid resolution issues.
Conclusion and Best Practices
The key to resolving JSTL URI resolution errors is maintaining version consistency: when using JSTL 1.2, only jstl-1.2.jar is needed, avoiding mixing with older jars. Developers should regularly update library files and refer to official documentation and community resources (such as Stack Overflow's JSTL tag page) for the latest compatibility information. By standardizing deployment processes and conducting thorough environment checks, such configuration errors can be significantly reduced, enhancing the stability and development efficiency of Web applications.