Servlet 2.3过滤器编程

摘要Jason Hunter通过对一些自由而又实用的过滤器的研究以对新的servlet过滤器模型进行深入探讨。你将知道这些过滤器是如何工作以及你能用他们做什么。最后，Jason介绍了他自己为简化文件上传而做的多路请求过滤器。   在"Servlet 2.3: New Features Exposed,"中，我介绍了Servlet API 2.3中的变化并给出了一个简单的servlet过滤器模型。在随后的文章中，我将对servlet过滤器进行深入的挖掘，而你看到的这些servlet过滤器都是能从Web上免费下载的。对每一个过滤器，我将检视它是做什么的，如何工作的，以及你能从哪里得到它。你可以在两种情况下使用本文：学习过滤器的功用，或者作为你写过滤器时的辅助。我将从几个简单的例子开始然后继续更多高级的过滤器。最后，我将向你介绍我为了支持多路请求而写的一个文件上传过滤器。Servlet 过滤器也许你还不熟悉情况，一个过滤器是一个可以传送请求或修改响应的对象。过滤器并不是servlet，他们并不实际创建一个请求。他们是请求到达一个servlet前的预处理程序，和/或响应离开servlet后的后处理程序。就像你将在后面的例子中看到的，一个过滤器能够：·在一个servlet被调用前截获该调用·在一个servlet被调用前检查请求·修改在实际请求中提供了可定制请求对象的请求头和请求数据·修改在实际响应中提供了可定制响应对象的响应头和响应数据·在一个servlet被调用之后截获该调用    你可以一个过滤器以作用于一个或一组servlet，零个或多个过滤器能过滤一个或多个servlet。一个过滤器实现java.servlet.Filter接口并定义它的三个方法：1．              void init(FilterConfig config) throws ServletException:在过滤器执行service前被调用，以设置过滤器的配置对象。2．              void destroy();在过滤器执行service后被调用。3．              Void doFilter(ServletRequest req,ServletResponse res,FilterChain chain) throws IOException,ServletException;执行实际的过滤工作。服务器调用一次init(FilterConfig)以为服务准备过滤器，然后在请求需要使用过滤器的任何时候调用doFilter()。FilterConfig接口检索过滤器名、初始化参数以及活动的servlet上下文。服务器调用destory()以指出过滤器已结束服务。过滤器的生命周期和servelt的生命周期非常相似 ——在Servlet API 2.3 最终发布稿2号 中最近改变的。先前得用setFilterConfig(FilterConfig)方法来设置生命周期。在doFilter()方法中，每个过滤器都接受当前的请求和响应，而FilterChain包含的过滤器则仍然必须被处理。doFilter()方法中，过滤器可以对请求和响应做它想做的一切。（就如我将在后面讨论的那样，通过调用他们的方法收集数据，或者给对象添加新的行为。）过滤器调用chain.doFilter()将控制权传送给下一个过滤器。当这个调用返回后，过滤器可以在它的doFilter()方法的最后对响应做些其他的工作；例如，它能记录响应的信息。如果过滤器想要终止请求的处理或或得对响应的完全控制，则他可以不调用下一个过滤器。循序渐进如果想要真正理解过滤器，则应该看它们在实际中的应用。我们将看到的第一个过滤器是简单而有用的，它记录了所有请求的持续时间。在Tomcat 4.0发布中被命名为ExampleFilter。代码如下：

当服务器调用init()时，过滤器用config变量来保存配置类的引用，这将在后面的doFilter()方法中被使用以更改ServletContext。当调用doFilter()时，过滤器计算请求发生到该请求执行完毕之间的时间。该过滤器很好的演示了请求之前和之后的处理。注意doFilter()方法的参数并不是HTTP对象，因此要调用HTTP专用的getRequestURI()方法时必须将request转化为HttpServletRequest类型。使用此过滤器，你还必须在web.xml文件中用<filter>标签部署它，见下：  

这将通知服务器一个叫timerFiter的过滤器是从TimerFiter类实现的。你可以使用确定的URL模式或使用<filter-mapping>标签命名的servelt 来注册一个过滤器，如：

这种配置使过滤器操作所有对服务器的请求（静态或动态），正是我们需要的计时过滤器。如果你连接一个简单的页面，记录输出可能如下：2001-05-25 00:14:11 /timer/index.html: 10ms在Tomcat 4.0 beta 5中，你可以在server_root/logs/下找到该记录文件。此过滤器的WAR文件从此下载：    http://www.javaworld.com/jw-06-2001/Filters/timer.war谁在你的网站上？他们在做什么？我们下一个过滤器是由OpenSymphony成员写的clickstream过滤器。这个过滤器跟踪用户请求（比如：点击）和请求队列（比如：点击流）以向网络管理员显示谁在她的网站上以及每个用户正在访问那个页面。这是个使用LGPL的开源库。在clickstream包中你将发现一个捕获请求信息的ClickstreamFilter类，一个像操作结构一样的Clickstream类以保存数据，以及一个保存会话和上下文事件的ClickstreamLogger类以将所有东西组合在一起。还有个BotChecker类用来确定客户端是否是一个机器人（简单的逻辑，像“他们是否是从robots.txt来的请求?”）。该包中提供了一个clickstreams.jsp摘要页面和一个viewstream.jsp详细页面来查看数据。我们先看ClickstreamFilter类。所有的这些例子都做了些轻微的修改以格式化并修改了些可移植性问题，这我将在后面将到。

doFilter()方法取得用户的session，从中获取Clickstream，并将当前请求数据加到Clickstream中。其中使用了一个特殊的FILTER_APPLIED标记属性来标注此过滤器是否已经被当前请求使用（可能会在请求调度中发生）并且忽略所有其他的过滤器行为。你可能疑惑过滤器是怎么知道当前session中有clickstream属性。那是因为ClickstreamLogger在会话一开始时就已经设置了它。ClickstreamLogger代码：

     logger（记录器）获取应用事件并将使用他们将所有东西帮定在一起。当context创建中，logger在context中放置了一个共享的流map。这使得clickstream.jsp页面知道当前活动的是哪个流。而在context销毁中，logger则移除此map。当一个新访问者创建一个新的会话时，logger将一个新的Clickstream实例放入此会话中并将此Clickstream加入到中心流map中。在会话销毁时，由logger从中心map中移除这个流。4000下面的web.xml部署描述片段将所有东西写在一块：  

  

    这注册了ClickstreamFilter并设置其处理*.jsp和*.html来的请求。这也将ClickstreamLogger注册为一个监听器以在应用事件发生时接受他们。   两个JSP页面从会话中取clickstream数据和context对象并使用HTML界面来显示当前状态。下面的clickstream.jsp文件显示了个大概：

这个包很容易从OpenSymphony下载并安装。将Java文件编译并放在WEB-INF/classes下，将JSP文件放到Web应用路径下，按帮助修改web.xml文件。为防止在这些工作前的争论，你可以从 http://www.javaworld.com/jw-06-2001/Filters/clickstream.war处找到打好包的WAR文件。 为能让此过滤器能在Tomcat 4.0 beta 5下工作，我发现我不得不做一些轻微的改动。我做的改动显示了一些在servlet和过滤器的可移植性中通常容易犯的错误，所以我将他们列在下面：·我不得不将在JSP中添加一个额外的导入语句：<%@ page import=”Clickstream” %>。在Java中你并不需要导入在同一包下的类，而在服务器上JSP被编译到默认包中，你并不需要这句导入行。但在像Tomcat这样的服务器上，JSP被编译到一个自定义的包中，你不得不明确地从默认包中导入类。·我不得不将<listener>元素移动到web.xml文件中的<filter>和<filter-mapping>元素之后，就像部署描述DTD要求的那样。并不是所有服务器对元素都要求固定的顺序。但Tomcat必须要。·我不得不将web.xml中的映射由/*.html和/*.jsp改成正确的*.html和*.jsp。一些服务器会忽略开头的/，但Tomcat强硬的规定开头不能有/。·最后，我得将ClickstreamFilter类升级到最新的生命周期API，将setFilterConfig()改成新的init()和destory()方法。可下载的WAR文件已经包含了这些修改并能通过服务器在包外运行，虽然我并没有广泛的进行测试。压缩响应第三个过滤器是自动压缩响应输出流，以提高带宽利用率并提供一个很好的包装响应对象的示例。这个过滤器是由来自SUN的Amy Roh编写的，他为Tomcat 4.0 的“examples”Web程序做出过贡献。你将从webapps/examples/WEB-INF/classes/compressionFilters下找到原始代码。这里的例子代码以及WAR下的都已经为了更清晰和更简单而编辑过了。CompressionFilter类的策略是检查请求头以判定客户端是否支持压缩，如果支持，则将响应对象用自定义的响应来打包，它的getOutputStream()和getWriter()方法已经被定义为可以利用压缩过的输出流。使用过滤器允许如此简单而有效的解决问题。我们将从init()开始看代码：  

注意在检索请求头前必须把request转化为HttpServletRequest，就想在第一个例子里那样。过滤器使用wrapper类CompressResponseWrapper，一个从HttpServletResponseWrapper类继承下来的自定义类。这个wrapper的代码相对比较简单：

所有调用getOutputStream() 或者getWriter()都返回一个使用CompressResponseStream类的对象。CompressionResponseStrteam类没有显示在这个例子中，因为它继承于ServletOutputStream并使用java.util.zip.GZIPOutputStream类来压缩流。Tomcat的”examples”Web程序中已经预先配置了这个压缩过滤器并加载了一个示例servlet。示例servlet响应/CompressionTestURL（确定先前的路径是/examples）。使用我制作的有用的WAR文件，你可以用/servlet/compressionTest(再次提醒，别忘了适当的前导路径)访问此测试servlet。你可以使用如下的web.xml片段来配置这个测试：