JSTL 1.2 - The absolute uri: http://java.sun.com/jstl/core cannot be resolved

序

上周五，公司临时决定把一个老项目要部署到外边。事前我也没有接到通知，下午要下班的时候，突然跟我说要部署项目，而且那边很着急用，没办法，只能加班等待部署完成了。

背景

简单的说一下项目的背景。之所以说是老项目，是因为这个项目是从别的公司接过来的，项目的架构采用的是 JSTL + SpringMVC + Spring + MyBatis ，前端页面用的是 JSTL 1.2 的版本。背景介绍完了，下面讲讲出现的问题。

正文

运维人员在部署的时候，反馈说项目部署成功，tomcat 启动也没有报错，但是在访问的时候，总是提示“The absolute uri: http://java.sun.com/jstl/core cannot be resolved”的错误。没办法，根据运维人员提供的信息，赶快找解决方案吧。于是就在网上寻扎各种解决方案。

下面是查找到的解决方案。

• 一种可能是版本问题导致的

JSTL 1.1 的声明是：<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core " %>。

而 JSTL1.2 的版本声明是：<%@ taglib prefix="c" uri=http://java.sun.com/jsp/jstl/core %>。

• 另一种可能是，项目中缺少 jar 包

项目在编译的时候，是包含有 jstl-1.2.jar 文件的，但是部署到 tomcat 中，就会发现没有这个 jar 包，解决的办法是，手动导入该 jar 包到 tomcat 的部署路径中。

• 第三种可能是，jsp 页面中没有导入标签库的 uri

这种可能性的问题在于，页面在使用 jstl 时，没有在页面头部导入相应的标签库 uri，例如，应该导入如下  uri。

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

• 第四种可能是，web.xml 文件没有配置 <taglib> 信息

这种可能性的问题在于，使用了 jstl 之后，没有在 web.xml 中配置 <taglib> 的信息，如下所示。

<span style="font-family:Comic Sans MS;font-size:12px;"><jsp-config>   <taglib>    <taglib-uri>http://java.sun.com/jsp/jstl/core</taglib-uri>    <taglib-location>/WEB-INF/c.tld</taglib-location>   </taglib>   <taglib>    <taglib-uri>http://java.sun.com/jsp/jstl/xml</taglib-uri>    <taglib-location>/WEB-INF/x.tld</taglib-location>   </taglib>   <taglib>    <taglib-uri>http://java.sun.com/jsp/jstl/fmt</taglib-uri>    <taglib-location>/WEB-INF/fmt.tld</taglib-location>   </taglib>   <taglib>    <taglib-uri>http://java.sun.com/jsp/jstl/sql</taglib-uri>    <taglib-location>/WEB-INF/sql.tld</taglib-location>   </taglib></jsp-config></span>

仍未解决

找了这么多的解决方案，项目还是出现同样的问题，这个问题还是没有解决。后来我就回想，项目在公司里部署的时候，是没有出现过这个问题的，而且，上面的这些解决方案，项目中也都配置了，该有的 jar 包也都有，版本问题也注意到了，而且，在我本地电脑上是可以跑起来的，访问页面也没有出现这样的问题。

最后，我真的快要放弃了，后来运维人员说到了 tomcat，于是我就想，会不会是容器的问题啊，于是我就追问运维人员的 tomcat 是用的哪个版本，从哪里找的。根据运维人员的反馈，我了解到，似乎 tomcat 不应该有问题啊，也就没在意。但是，出现这样的问题，真的让人恼火。

找不到解决方案，最后，只能先让运维换一个 tomcat 容器，使用之前部署的那个 tomcat 试试看，谁知道运维换了 tomcat 之后，这个问题就不再出现了。最终，他给我的反馈结果是，之前有问题的那个 tomcat 针对别的项目做过优化，因此部署这个项目的时候有冲突，才会出现这样的情况。好吧，我真的没想到还可以这样。看来，以后交给运维人员部署的时候，还是要交代清楚比较好，以免出现其他的问题。

最终解决方案

• 使用未优化过的 tomcat 容器
• 或者检查 tomcat 容器是否有针对某个项目的个别优化，避免产生影响

结束语

就因为这一个问题，周五晚上一直加班到了10点多，最后却发现是容器捣的鬼，这也说明了一个问题，我日常的开发，使得我形成了一个惯性思维，在项目可以运行的情况下出现问题，不仅仅只是项目本身的问题，还有可能是容器的问题，以及其他版本兼容性的问题。这些是都要考虑的。