Java Servlet 3.0 规范发布最终建议草案

Servlet 3.0 规范的一个主要目标是无需手动修改应用程序 web.xml 文件，即可部署 servlet，filter（过滤器）和 listener（监听器）等。新的特征包括：

• Annotation（注释）在 filter 和 servlet 中的使用，让部署它们时可以不用在 web.xml 中声明相关条目。
• 支持“web 片段（fragment）”，由开发人员提供配置信息，无需手动编辑 web.xml 文件。XML 片段放置于 _/META-INF/web-fragments.xml_ 文件中，它包含大部分与 web.xml 描述符相同的元素。容器将在部署时处理这些 XML 片段，并配置最终的描述符。
• 源于 _ServletContextListeners_ 的对 filter 和 servlet 的编程式配置，这些配置会被放在 jar 包中的 _/META-INF/*.tld_ 文件里。

在早期草案审阅阶段，这些特征引起过一些争论。一些专家组成员担心会有严重的安全风险，诸如部署了非预期的filter 和servlet，无论这是偶然的或是故意混淆的结果。专家组成员Greg Wilkins 在他言辞激烈的博文中将这一规范描述为“糟糕的文档以及缺陷流程下工作不和谐的专家组的成果”。最终建议草案中讨论了大部分以上被关注的问题，包括指定多个jar 文件的绝对顺序，以及允许排除个别jar 文件。它以如下方式工作：借助_META-INF/web-fragment.xml_ 文件中的元素，_WEB-INF/lib_ 中的每个jar 文件被赋予一个对应的名字。Web 应用的_WEB-INF/web.xml_ 将包含元素，并以应用的顺序列出以上的片段名，同时它还有一个可选的元素，用于标识是否以及何时包含（include）那些未被命名的jar 文件。部署者可以选择只部署那些列表中可信的jar 文件，以防止意外部署的问题。此外，在找到web-fragment.xml 文件之前，顺序的特性可以排除（exclude）那些不需要扫描的jar 文件，因此加速了应用的部署。

除了支持片段以及使用注释，专家组所设定的另一个需求是可以插入框架共享副本，包括JAX-WS，JAX-RS 和JSF 等构建在Web 容器之上的框架。公开评阅草稿中加入的_ServletContainerInitializer_ 正是用于处理这个用例。 ServletContainerInitializers_ 通过 jar 服务 API 被发现，另外它指定它所能处理的一系列类型。任何包含在 _WEB-INF/lib_ 下 jar 文件里的的这些类型的类（Class），在发现后会被传递给 _ServletContainerInitializer，它能够使用与 _ServletContextListeners_ 相同的编程式来配置 APIs。尽管这点广受欢迎，但 _ServletContainerInitializer_ 也的确引出了另一个新的问题，正如 Wilkins 在后续的博文中所强调的那样，目前仍不清晰的是使用绝对的顺序机制能否排除 _ServletContainerInitializer_。他给出了一些自己的建议，以澄清这一点：

如果 web.xml 具有一个不包含元素的，那么只有在顺序中列出的包含片段的 jar 文件才可以通过注释和可插拔（Pluggability）特征实例化 Filter、Listener 和 Servlet 等。具体来说： - 被排除的 jar 文件的 web-fragment.xml 不会被处理；

• 对于注释的 servlet，filter 或 listener，被排除的 jar 文件不会被扫描。但是，如果一个源于被排除的 jar 的 servlet，filter 或者 listener 被列在了 web.xml 或者非排除性的 web-fragment.xml 中，除非它被 metadata-complete 所排除，那么这些注释将被采用。
• 在被排除的 jar 文件的 TLD 文件中所发现的 ServletContextListeners 将不能够通过编程式 APIs 配置 filter 和 servlet。任何这样的尝试将导致 IllegalStateException 异常。
• 如果从被排除的 jar 文件中装载一个发现的 ServletContainerInitializer，它将会被忽略。
• 在 ServerletContainerInitializers 处理类时，将不会扫描被排除的 jar 文件。

除了这些易于使用的特征，JSR-315 还添加了对异步请求的支持，它允许线程提前返回容器并执行其他任务。这个特征备受争议，专家组试图利用已有的 RequestDispatcher 处理异步的重分发。讨论的结果是，新规范添加了 20 个方法和 3 个新的接口。由于其复杂性，在公开审阅阶段被广泛批评。最终建议草案定义了一个明确的分发类型：AsyncContext.dispatch，它被用于执行异步请求，并包含相当简化了的 API。@WebServlet_ 和@WebFilter_ 注释具有一个 boolean 型的属性：asyncSupported，缺省为 false。当它被设为 true 时，应用程序可以通过调用 _startAsync_ 启动另一个分离的线程进行异步处理，同时传递给它到 request（请求）和 response（响应）对象的引用，之后从容器里的原线程退出。这意味着 response 将沿着与进来相同的路径反序遍历这些过滤器（或过滤器链）。当异步处理从 request 开始时，另一个线程或者回调（callback）也可以产生 response 并调用 _complete_ 方法，或者通过 _AsyncContext.dispatch_ 方法将 request 分发出去，以便它在容器的上下文环境中运行。

查看英文原文： Java Servlet 3.0 Specification Reaches Proposed Final Draft

译者简介：刘一鸣，目前在复旦大学攻读计算机软件与理论博士学位。主要从事分布式系统、分布式数据库、协同计算等领域的研究和开发工作。关注系统架构、云计算进展。希望自己的专业知识可以为更多人服务。业余时间大部分贡献给了书籍，希望将来可以有家自己的书店。给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors[AT]cn.infoq.com 。