对filter的初步认识

　　Filter 技术是servlet 2.3 新增加的功能。servlet2.3是sun公司于2000年10月发布的，它的开发者包括许多个人和公司团体，充分体现了sun公司所倡导的代码开放性原则。在众多参与者的共同努力下，servlet2.3比以往功能都强大了许多，而且性能也有了大幅提高。

它新增加的功能包括:

　　1. 应用程序生命周期事件控制;

　　2. 新的国际化;

　　3. 澄清了类的装载规则;

　　4. 新的错误及安全属性;

　　5. 不赞成使用HttpUtils 类;

　　6. 各种有用的方法;

　　7. 阐明并扩展了几个servlet DTD;

　　8. filter功能.

　　其中最重要的就是filter功能.它使用户可以改变一个request和修改一个response. Filter 不是一个servlet，它不能产生一个response，它能够在一个request到达servlet之前预处理request，也可以在response离开servlet时处理response.换种说法，filter其实是一个"servlet chaining"(servlet 链)。

包括

　　1. 在servlet被调用之前截获;

　　2. 在servlet被调用之前检查servlet request;

　　3. 根据需要修改request头和request数据;

　　4. 根据需要修改response头和response数据;

　　5. 在servlet被调用之后截获.

三个方法

　　1. void setFilterConfig(FilterConfig config) //设置filter 的配置对象;

　　2. FilterConfig getFilterConfig() //返回filter的配置对象;

　　3. void doFilter(ServletRequest req,ServletResponse res,FilterChain chain) //执行filter 的工作

　　注:现setFilterConfig和getFilterConfig方法已取消，代之为init(FilterConfig config)和destory()方法。

服务器每次只调用setFilterConfig方法一次准备filter 的处理;调用doFilter方法多次以处理不同的请求.FilterConfig接口有方法可以找到filter名字及初始化参数信息.服务器可以设置FilterConfig为空来指明filter已经终结.

　　每一个filter从doFilter()方法中得到当前的request及response.在这个方法里，可以进行任何的针对request及response的操作.(包括收集数据，包装数据等).filter调用chain.doFilter()方法把控制权交给下一个filter.一个filter在doFilter()方法中结束.如果一个filter想停止request处理而获得对response的完全的控制，那它可以不调用下一个filter.

　　一个filter可以包装request 或response以改变几个方法和提供用户定制的属性.Api2.3提供了HttpServletRequestWrapper 和HttpServletResponseWrapper来实现.它们能分派最初的request和response.如果要改变一个方法的特性，必须继承wapper和重写方法.

连接过程

　　Filter只有加入到Filter Graph中并且和其它Filter连接成完整的链路后，才会发挥作用。Filter之间的连接(也就是Pin之间的连接)，实际上是连接双方的一个Media type的协商过程。连接的方向总是从Output pin指向Input pin。连接的大致过程为:如果调用连接函数时已经指定了完整的Media type，则用这个Media type进行连接，成功与否都结束连接过程;如果没有指定或不完全指定了Media type，则进入下面的枚举过程。枚举欲连接的Input pin上所有的Media type，逐一用这些Media type与Output pin进行连接(如果连接函数提供了不完全Media type，则要先将每个枚举出来的Media type与它进行匹配检查)，如果Output pin也接受这种Media type，则Pin之间的连接宣告成功;如果所有Input pin上枚举的Media type，Output pin都不支持，则枚举Output pin上的所有Media type，并逐一用这些Media type与Input pin进行连接。如果Input pin接受其中的一种Media type，则Pin之间的连接到此也宣告成功;如果Output pin上的所有Media type，Input pin都不支持，则这两个Pin之间的连接过程宣告失败。　　每个Pin都可以实现GetMediaType函数来提供该Pin上支持的所有Preferred Media type(但一般只在Output pin上实现，Input pin主要实现CheckMediaType看是否支持当前提供的Media type就行了)。连接过程中，Pin上枚举得到的所有Media type就是这里提供的。　　在CBasePin类中有一个protected的成员变量m_bTryMyTypesFirst，默认值为false。在我们定制Filter的Output pin中改变这个变量的值为true，可以定制我们自己的连接过程(先枚举Output pin上的Media type)。　　当Pin之间的连接成功后，各自的pin上都会调用CompleteConnect函数。我们可以在这里取得一些连接上的Media type的信息，以及进行一些计算等。在Output pin的CompleteConnect实现中，还有一个重要的任务，就是协商Filter Graph运行起来后Sample传输使用的内存配置情况。这同样是一个交互过程:首先要询问一下Input pin上的配置要求，如果Input pin提供内存管理器(Allocator)，则优先使用Input pin上的内存管理器;否则，使用Output pin自己生成的内存管理器。我们一般都要实现DecideBufferSize来决定存放Sample的内存大小。注意:这个过程协商完成之后，实际的内存并没有分配，而要等到Output pin上的Active函数调用。

参考资料：https://baike.so.com/doc/5450367-5688736.html