No TLD files were found in resource path [/WEB-INF/].

No TLD files were found in resource path [/WEB-INF/].

(注意：这个问题不影响项目启动）

简介：
tld是taglib description 的缩写(jsp中的自定义标签的解析文件，指出标签与标签实现类的关系)

详细的请看这个文章：https://blog.csdn.net/liaoxiaohua1981/article/details/6856307

定位问题的方法：（没时间就不用看了）
案例：
昨天帮别人调试一个问题, 他说项目访问不了, 我clone下来项目, 尝试启动, idea的控制台没有自定义的日志信息。没有啥有用的输出，没有报错，只有标题的那个告警。但网上又没找到跟什么标题相关的文章，当时感觉不是那个问题，但项目接口就是访问不了。接口调用返回302状态码。

思来想去，idea看起来是部署成功了，302不可能无缘无故地返回回来。

第一想法就是去验证项目最外层的index.jsp。如果能访问成功说明项目启动是没有问题的。
很尴尬的是我的也返回302.

于是我想到了外部请求进入项目的流程：tomcat接收到context匹配的请求，然后会按顺序依次执行web.xml的filter、interceptor，于是，我选了最上面的一个filter，看了下里面的逻辑，里面除了项目健康检查不需要鉴权外，其他所有url都需要鉴权，包括了index.jsp。如果鉴权不通过，返回了http状态码302。没有日志打印，尴尬。

解决问题
这其中反映了很多问题：

1. 研发的代码在必要的地方还是需要打印一下日志（log，不是system.out.print）。比如上面在返回302的时候，可以打印请求的url、入参，简要打印异常情况（比如鉴权失败），日志可以让别人快速调试定位你的bug（生产环境的关键部分的日志尤为重要，但也不能疯狂打印日志，不然日志文件会占满你的硬盘导致服务挂掉）
2. http状态码不能乱用，3xx的http状态码代表重定向的意思，很明显上面的业务属于鉴权失败，应该是401状态码才对。（《http权威指南》可以脑补一下）
3. 自己定位问题的思路有待优化，请求没有到达controller层。说明请求从发起端–>controller中间出现了问题。应该先分析整个请求的链路，请求发起–> 网络–>tomcat -->filter --> interceptor --> spring容器–>业务controller层，根据二分法，可以在filter看下是左半部分还是右半部分的问题。上面的场景里面，filter里面就直接找到了问题所在。如果还没有找到问题，就再继续二分法。

理论方法

1. 二分法 + 本地调试
   是我认为效率比较高的定位问题的方法了。二分法能大体确定问题出现在哪个部位。至于方法内，就只能调试或者看日志了。（感觉能解决90%的问题）

2. 如果作者不是自己而且未离职，自己瞎折腾了大概10~20分钟依旧没解决后，果断找他。

3. 如果作者已经离职，而且自己没有什么思路的时候，找个老练的组员当小黄鸭。看下能不能提供些思路。