1700484670
在这里定义了对所有以.do结尾的请求进行拦截，拦截后由FilterDispatcher的doFilter方法处理。过滤器是在启动时自动初始化，初始化完毕后立刻调用inti方法，在init方法中我们做了两件事情：
1700484671
1700484672
❑检查XML配置文件
1700484673
1700484674
所有的Action与视图的对应关系是在配置文件中配置的，因此若配置文件出错，该应用应该停止响应，这就需要在启动时对XML文件进行完整性检查和语法分析。
1700484675
1700484676
❑启动监视器
1700484677
1700484678
配置文件随时都可以修改，但是它修改后不应该需要重新启动应用才能生效，否则对系统的正常运行有非常大的影响，因此这里要使用到Listener（监听）行为了。
1700484679
1700484680
init方法需要做的这两件事情是非常重要的，而且都还包含了几种不同的设计模式。首先我们来看检查XML配置文件如何实现。先看我们定义的XML格式（框架中应该定义一个DTD文件，XML文件的模板，读者可以自行实现），如代码清单38-3所示。
1700484681
1700484682
代码清单38-3 XML配置文件
1700484683
1700484684
＜?xml version=“1.0”encoding=“UTF-8”?＞
1700484685
1700484686
＜mvc＞
1700484687
1700484688
＜action name=“loginAction”class=”{类名全路径}“method=“execute”＞
1700484689
1700484690
＜result name=“success”＞/index2.jsp＜/result＞
1700484691
1700484692
＜result name=“fail”＞/index.jsp＜/result＞
1700484693
1700484694
＜/action＞
1700484695
1700484696
＜/mvc＞
1700484697
1700484698
读者思考一下该怎么检查这个XML文件，有两个不同的检查策略：一是检查XML文件的语法是否正确；二是框架逻辑检查，这是什么意思呢？比如我们在xml文件中配置了一个类A，它只有一个方法methodA，在method中编写的配置文件为method=“methoda”，方法名写错了，那这样的配置是肯定不能运行的，需要框架逻辑检查把它揪出来。这两种不同的算法是完全可以替换的，而且很有必要替换，逻辑检查在应用启动的时候需要对所有的类进行过滤处理，牺牲的是效率，这在测试机上没有问题，在生产机上要花20分钟才能把一个应用启动起来，在分秒必争的业务系统中这是不允许的，因此就要求该算法可以退休，想用的时候（测试机环境）就用，不想用的时候（生产环境）就不用，想到什么模式了吗？策略模式，这两个算法都是对同样的源文件进行检查，只是算法不同，当然可以相互替换了。类图比较简单，就不再画了，我们直接看代码，抽象策略如代码清单38-4所示。
1700484699
1700484700
代码清单38-4 XML文件校验
1700484701
1700484702
public interface IXmlValidate{
1700484703
1700484704
//只有一个方法，检查XML是否符合条件
1700484705
1700484706
public boolean validate（String xmlPath）；
1700484707
1700484708
}
1700484709
1700484710
根据一个指定的路径，对XML进行校验，返回校验结果。普通XML校验如代码清单38-5所示。
1700484711
1700484712
代码清单38-5 普通XML校验
1700484713
1700484714
public class CommonXmlValidate implements IXmlValidate{
1700484715
1700484716
//XML语法检查，比如是否少写了一个结束标志
1700484717
1700484718
public boolean validate（String xmlPath）{
1700484719
[
上一页 ]
[ :1.70048467e+09 ]
[
下一页 ]