验证改为本地dtd

  以前使用ibatis从来都没有管过dtd的加载，可是有一天你的主机不允许你访问外网，你就悲剧了，因为dtd的校验不能通过了，这个本来个人感觉不应该有这么蹩脚的一步，去官网验证一次你本地的dtd，当然了官方也考虑到了用户应用可能不能联网，所以即便是远程校验失败，也不影响应用本身的启动。

        可是更为苛刻的要求出现了，就是一旦主机检测到应用对外有请求就直接将应用的启动进程cut掉了，那么悲剧了，因为经过我一天的测试发现这个验证的过程似乎一直都存在，也就是说如果上述成立那么你的应用将永远起不来了，网上有很多说法，比如自己写解析器，等等，这个已经不是去哪里解析的问题了，比如SqlMapClasspathEntityResolver这个类，它负责去加载dtd，如果你仅仅重写了她似乎也不能从本质上解决，因为上述问题的出现貌似跟他没有关系

        我做了一件无耻的事情，就是讲systemId指向了本地应用，比如：

Xml代码  

1. <?xml version="1.0" encoding="GB2312"?>  
2. <!DOCTYPE sqlMapConfig PUBLIC "-//ibatis.apache.org//DTD SQL Map Config 2.0//EN"  
3.         "sql-map-config-2.dtd">  

 

这样的话应为修改了SystemId（即："sql-map-config-2.dtd"）所以就需要手工将对应的dtd放置到应用的路径下，这里需要提醒一下，一般来说这个文件放置到应用根目录下就可以了，即与WEB-INF同级的目录下，正常情况也应该如此，本人犯了一个很傻的错误，就是在放置文件的时候觉得放置在应用根目录下有点别扭，就想着能不不能放置到配置文件路径下，由于项目采用的是maven多模块结构，就放在了业务逻辑层的src/main/resources目录下，为了定位（其实是不确定怎么加载）就将dtd文件在所有目录下都放置一边，部署后发现根本没起作用，最后就放置在了web模块的WEB-INF目录下，部署OK，当然了，如果你要放置到WEB-INF对应的模块中的某个目录下，就得在SystemId中指定具体的路径了

但我试了下dtd 放在web-inf 不是太给力 放到class同级目录可以验证通过