在web.xml中进行配置。对全部的URL请求进行过滤。就像"击鼓传花"一样,链式处理。
配置分为两种A和B。
A:普通配置
B:高级配置(同意代理注入Spring bean)
由于filter比bean先载入,也就是spring会先载入filter指定的类到container中。这样filter中注入的spring bean就为null了。
解决的方法:
先filter中增加DelegatingFilterProxy类,"targetFilterLifecycle"指明作用于filter的全部生命周期。 原理是,DelegatingFilterProxy类是一个代理类。全部的请求都会首先发到这个filter代理,然后再依照"filter-name"委派到spring中的这个bean。在Spring中配置的bean的name要和web.xml中的<filter-name>一样.
此外,spring bean实现了Filter接口。但默认情况下,是由spring容器来管理其生命周期的(不是由tomcat这样的server容器来管理)。假设设置"targetFilterLifecycle"为True。则spring来管理Filter.init()和Filter.destroy();若为false,则这两个方法失效!
!
B和A最大的不同是,A是一个filter。优先被载入到container中。无法调用spring中兴许的bean;而B是一个spring bean,能够引用其它的bean。而请求都通过DelegatingFilterProxy类委派给B!
B的第二种配置方式:
也就是添加一个"targetBeanName"的參数,值为实际运行Filter的bean。
注意:Filter和servlet都能够对URL进行处理。Filter是一个链式处理,仅仅要你想继续处理就能够传递下去;而Servlet则是一次处理并返回!
适合简单逻辑处理。
附录:
<url-pattern>能够选择下面几种形式 /* 全部资源 *.html 以html结尾的资源 /fold/* 指定文件夹 /abc.html 指定文件 以”/’开头和以”/*”结尾的是用来做路径映射的, 曾经缀”*.”开头的是用来做扩展映射的。 为什么定义”/*.action”这样一个看起来非常正常的匹配会错? 由于这个匹配即属于路径映射。也属于扩展映射,导致容器无法推断。 此外,filter就像"递归",在web.xml配置中的顺序代表了filter的调用流程,而servlet被调用后不会继续调用其它的servlet!因此配置中的顺序不影响!小结:工作之后才知道,每天能够积累的东西非常多,但的确没多少时间写出来!理解一个东西须要花点时间,但写出来就须要花很多其它的时间……写出来的优点就不用多说了。希望以后多挤一些时间。好好沉淀下。