有些技能只有踩过坑的人才能够掌握,能用来避免后来的坑,很多时候是用凌晨的时间换来的，我们通常把他叫做经验。
故事
这个一个关于springmvc的坑的故事。
某天晚上本打算一个小功能分分钟搞定上线,但页面总是报404错误,肉眼实在找不到原因。
各种手段折腾,断点,重启,重新打包,拍脑袋觉得代码没写错,url路径也ok,真心没问题，无数次f5就是不出来。
很多时候遇到一个bug越着急越搞不定，我就是这种情况，花了一两个小时时间，眼看都过0点了，此时我正用最后的手段，引入spring源码直接一步步debug，看起来也没问题，那能不能更深入点，从spring启动开始。
这时我突然想到了日志，平时线上的日志级别都是error，本地一般也很少改，大多数情况都是断点debug，日志更多的是用来日后线上问题排查。所以我改了下spring的日志级别，看看他启动干了啥。
因此，修改了下log4j的配置文件，将springmvc的日志级别改为debug，如果是logback的话，配置文件也是类似。
<logger name="org.springframework.web">
<level value="DEBUG"/>
</logger>
这样的话启动后，springmvc就会打印出它所加载的路径映射，每次请求也会详细打印出请求的参数，路径等等。
然后，重启，看到控制台打印出来的路径和我实际访问的路径，问题一目了然了，原来我与显示页面只差一个字母大小写的距离。看一下时间，已然是凌晨1点，默默的在心里说一句：WTF。然后倒头就睡。
合理的日志级别
日志是我们经常用到的东西,但很多时候只有在遇到线上bug之类的情况才会想起有日志可以协助排查,但开发的时候一点点日志级别修改,就能避免某个bug调试到凌晨1点才发现与答案只差一个字母的距离。
我个人的经验，在web项目时会把三个方面的日志级别改为debug
- webmvc框架：springmvc 或者struts2，主要查看请求路径和参数，页面400，404了，看看请求路径和参数对不对；
- orm框架：如mybatis，debug级别会打印sql和参数，有sql异常通过日志就可以很快定位；
- 项目本身的业务日志，这个一般很少。
至于其他外部依赖的项目根据需要自行定义，root日志级别一般是error，不然很多其他日志混进来会导致很难查看。
对于struts2，日志级别是这么定义的。
<logger name="com.opensymphony.xwork2">
<level value="DEBUG"/>
</logger>
当然这是xml格式的配置文件，如果是properties，需要这么做
log4j.logger.com.opensymphony.xwork2=debug
mybatis的sql则可参考如下
log4j.logger.com.ibatis=debug
log4j.logger.java.sql.Connection=debug
log4j.logger.java.sql.PreparedStatement=debug
本文于2016-07-07 18:32:58从Chu Lung‘s blog自动同步同步,访问原文