Servlet 3.0 新特性详解
Java servlets 是一项被普遍接受的技术，用于构建基于 web 应用程序的动态内容；Servlet 3.0 规范早期草案版本的发行让该技术在特性和应用程序接口（Application Program Interface，API）方面得到了极大增强。Java Specification Request（JSR）已经以 JSR 315 的形式得到了批准，并计划成为 Java Enterprise Edition 6（JSR 316）或更高版本的组成部分。与之前仅仅是维护发行版（maintenance releases）的一些版本规范不同，Servlet 3.0 规范随带了许多 web 开发新时代所需的最令人兴奋的特性。在本文中，我们将研究新版 Java servlets 中引入的主要特性。值得注意的是，本规范仍处于草案版本阶段，因此在本文中所讨论的技术细节可能会发生变化。
新规范主要交付了以下新特性：
● 开发的简易性
● 可插拔性和可扩展性
● 异步支持
● 安全性增强
● 其他杂项变化
很明显，与其他技术相比，servlets 在 Java Enterprise Edition 家族中有着更广泛的应用。Servlets 保留了其简洁性和能够处理 HTTP 请求并向 web 客户机传回响应的优点。Servlets 可以用于实现简单和小型应用程序的业务逻辑。在 web 框架中，servlets 作为所有传入请求的入口点（即 controller servlet）；因此，所有流行框架都是在原始的 servlets 上建立的。Servlet 3.0 中的新增特性旨简化 servlet 应用程序的开发，并让 servlet 开发人员和框架开发人员从中受益。在以下章节中，我们将详细介绍每个新增特性，并讨论如何使用它们来开发更优秀的应用程序。
开发的简易性
开发的简易性是任何技术成功的关键因素。Servlet 3.0 API 通过使用 JSR 175 注释 集中解决开发简易性问题，允许开发人员采用声明式的编程方式。这意味着您可以通过使用像 @Servlet 或者 @ServletFilter 这样的适当注释对类进行注释来快速开发一个 servlet 或者过滤器类。注释不仅使 servlet、过滤器和侦听器类的编码更容易，而且，即使应用程序存档可能有 servlet、过滤器或者上下文侦听器类也可以选择用于 web 应用程序的开发部署描述符。Web 容器负责处理各种注释，其位置在 WEB-INF/classes 目录下的各个类中、WEB-INF/lib 目录下的 .jar 文件中、或者应用程序类路径中任何可以找到的类中。
注释与部署描述符
值得注意的是，部署描述符优先于注释。换句话说，部署描述符覆盖通过注释机制所规定的配置信息。Web 部署描述符的 3.0 版本在 web-app 元素上包含一种名为 metadata-complete 的新属性。该属性定义了 web 描述符是否完整，或者 web 应用程序的类文件是否针对指定部署信息的注释而进行检查。如果该属性被设置为 true，则部署工具必须忽略类文件中所存在的任何 servlet 注释，并只使用描述符中所提及的配置细节。否则，如果没有指定该值或者该值被设置为 false，容器必须针对注释而扫描应用程序的所有类文件。这个属性提供了在应用程序启动阶段启用或者禁用注释扫描以及对注释的处理。
在 Servlet 3.0 中所引入的所有注释都可以在 javax.servlet.http.annotation 和 javax.servlet.http.annotation.jaxrs 软件包中找到。以下章节阐述 Servlet 3.0 中注释的完整集合：
@Servlet：javax.servlet.http.annotation.Servlet 是一个类级别的注释，确认经过注释的类为一个 servlet 并保存关于所声明的 servlet 的元数据。urlMappings 属性是指定 URL 模式（调用该 servlet）的 @Servlet 的强制属性。当接收到了一个请求时，容器将请求中的 URL 与 servlet 的 urlMappings 进行匹配，且如果 URL 模式匹配，则调用相应的 servlet 以响应该项请求。该注释的所有其他属性都是可选的，并带有合理的默认值。Servlet 类中必须有一种使用像 GET、PUT、POST、HEAD 或者 DELETE 这样的 HttpMethod 注释进行注释的方法。这些方法应将 HttpServletRequest 和 HttpServletResponse 作为方法参数。与以前的版本相反，servlets 3.0 的版本可以作为简单传统 Java 对象（Plain Old Java Objects，POJOs）而实现；也就是 servlets 不必再扩展像 HTTPServlet 或者 GenericServlet 这样的基础 servlet 实现类。
为了进行比较，在此给出了使用传统 Servlet 2.5 API 编写的 Java servlet 代码片段，如下所示。在 Servlet 2.5 中，只要在部署描述符中配置了 servlet 的详细信息，web 容器就将初始化 servlet。
public class MyServlet extends HttpServlet {
public void doGet (HttpServletRequest req,
HttpServletResponse res) {
....
}
}
Deployment descriptor (web.xml)
<web-app> <servlet> <servlet-name>MyServlet</servlet-name> <servlet-class>samples.MyServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>MyServlet</servlet-name> <url-pattern>/MyApp</url-pattern> </servlet-mapping> ... </web-app>
这里给出的是使用 Servlet 3.0 API 编写的较为简化的版本。当 MyServlet 使用 @Servlet 注释而被注释为一个 servlet 时，则在 web 容器的启动期间对其初始化。注意，在这种情况下部署描述符是可选的。
@Servlet(urlMappings={"/MyApp"})
public class MyServlet {
@GET
public void handleGet(HttpServletRequest req,
HttpServletResponse res) {
....
}
}
Deployment descriptor (web.xml)
optional
@ServletFilter 和 @FilterMapping：您可以使用 javax.servlet.http.annotation.ServletFilter 注释来注释过滤器类，从而轻松创建一个 servlet 过滤器。该注释封装正被声明的过滤器的有关元数据。在过滤器类上具有 @FilterMapping 注释也是强制性的。@FilterMapping 注释定义用于过滤器的 URL 模式。@ServletFilter 的所有其他属性都是可选的，并带有合理的默认值。V3.0 过滤器类现在类似 POJO 类，并且没有用于这些类所需的 Filter 接口或者非参数公用构造器。以下给出了使用 Servlet v2.5 API 的过滤器类的代码片段：
public class MyFilter implements Filter {
public void doFilter(ServletRequest req,
ServletResponse res,
FilterChain chain)
throws IOException, ServletException {
......
}
}
Deployment descriptor (web.xml)
<web-app> <filter> <filter-name>My Filter</filter-name> <filter-class>samples.MyFilter</filter-class> </filter> <filter-mapping> <filter-name>My Filter</filter-name> <url-pattern>/foo</url-pattern> </filter-mapping> ... </web-app>
使用 Servlet 3.0 编写的一个示例过滤器类如下所示。因为该类使用 ServletFilter 注释，所以容器将 MyFilter 标记为一个过滤器类。MyFilter 截取所有收到的请求，其中该请求的 URL 匹配模式 /foo。Servlet 3.0 为过滤器配置提供了可选的部署描述符。
@ServletFilter
@FilterMapping("/foo")
public class MyFilter {
public void doFilter(HttpServletRequest req,
HttpServletResponse res) {
.....
}
}
Deployment descriptor (web.xml)
optional
@InitParam：该注释可以用来定义必须传递给 servlet 或者过滤器类的任意初始化参数。它是 @Servlet 和 @ServletFilter 注释的一个属性。以下代码示例解释了如何将具有 english 值、称作 lang 的初始化参数传递给一个 servlet 类。
@Servlet(urlMappings={"/MyApp"}, initParams ={@InitParam(name="lang", value="english")})
public class MyServlet {
@GET
public void handleGet(HttpServletRequest req,
HttpServletResponse res) {
....
}
}
@ServletContextListener：javax.servlet.http.annotation.ServletContextListener 注释将该类声明为一个 servlet 上下文侦听器。当 web 容器创建或者销毁 ServletContext 时，该上下文侦听器接收注释。上下文侦听器是一个 POJO 类，且不必实现 ServletContextListener 接口。使用 Servlet 2.5 API 编写的侦听器类如下所示。当且仅当您在部署描述符中配置了该侦听器类，容器才识别它。
public class MyListener implements ServletContextListener {
public void contextInitialized(ServletContextEvent sce) {
}
.....
}
Deployment Descriptor (web.xml)
<web-app>
<listener>
<listener-class>samples.MyListener</listener-class>
</listener>
....
</web-app>
使用 Servlet 3.0 API 编写的一个得到极大简化的侦听器类，如下所示。
@ServletContextListener
public class MyListener {
public void contextInitialized (ServletContextEvent sce) {
}
.....
}
Deployment Descriptor (web.xml)
optional
可插拔性和可扩展性
如今，像 Struts、JSF 和 Springweb 这样的 web 框架已经被普遍接受，并已经确立成为构建 web 应用程序的技术。将这些框架集成为一个 web 应用程序并不是那么容易，因为这一过程涉及将不同的片段同化在一起，之后编辑一个描述如何将所有这些片段配合在一起的单独描述符文件。绝大多数框架强制您在应用程序的部署描述符文件中配置像 servlet 类（通常为 控制器 Servlet）、过滤器类或者侦听器类这样的框架细节。这种必备配置的主要原因是当今的 web 应用程序只支持一个单独的整体部署描述符，其中定义了所有的部署信息。当应用程序的大小增加时，外部框架的依赖关系可能也增加，从而生成复杂的部署描述符文件。正如您可能知道的，复杂描述的维护始终存在争议。
为了解决这些问题，Servlet 3.0 最为显著的概念之一是 web 片段 或者 模块 web.xml 的思想。Web 片段是将 web 应用程序逻辑分区为 servlet、servlet-mapping、servlet-filter、filter-mapping、servlet-listener 之类的元素及其子元素。框架开发人员可以利用该功能以定义存在于框架内自己的 web 片段，开发人员可以在不修改现有的部署描述符的情况下仅仅通过将库文件包含到应用程序的类路径中来插入越来越多的框架。简言之，该功能旨在当用框架或者库进行工作时进行零配置。
对该部署描述符已经进行了更改以包含保存 web 片段细节的 <web-fragment> 这一新元素。如果该片段被打包为一个 .jar 文件且以部署描述符的形式具备元数据信息，则 web.xml 文件必须包含在 .jar 文件的 META-INF 目录下。在部署时，器扫描应用程序的类路径，查找所有 web 片段并加以处理。前面讨论过的 metadata-complete 标志在应用程序启动期间控制 web 片段的扫描。以下显示了一个示例 web 片段：
<web-fragment> <servlet> <servlet-name>myservlet</servlet-name> <servlet-class>samples.MyServlet</servlet-class> </servlet> <listener> <listener-class>samples.MyListener</listener-class> </listener> </web-fragment>
为了提供增强的可插拔性，Servlet 3.0 借助添加到 ServletContext 的 API 为增加 servlets 和过滤器类的编程提供了非常需要的支持。这些新的 API 使您能通过编程来声明 servlets、过滤器类及其 URL 映射。这些类在应用程序启动或者运行期间进行初始化。最重要的是，您只能通过 ServletContext 的 contextInitialized 方调用这些 API。有关这些 API 的更多信息，请参阅 Servlet 3.0 API 文档。通过编程添加 servlet 和过滤器类的代码示例如下所示：
@ServletContextListener
public class MyListener {
public void contextInitialized (ServletContextEvent sce) {
ServletContext sc = sce.getServletContext();
//Declare servlet and servlet mapping
sc.addServlet("myServlet", "Sample servlet", "samples.MyServlet", null, -1);
sc.addServletMapping("myServlet", new String[] {"/urlpattern/*"});
//Declare filter and filter mapping
sc.addFilter("myFilter", "Sample Filter", " samples.MyFilter", null);
sc.addFilterMapping("myFilter", new String[] {"/urlpattern/*"}, "myServlet",
DispatcherType.REQUEST, false);
}
}
异步支持
大家应该都遇到过 servlets 运行缓慢的问题，特别是 servlets 必须等待来自 web 服务、JDBC 连接、JMS 消息等的响应。在当前情况下，servlet 在生成响应前需要等待进程完成，这会导致低效率阻塞操作消耗容器的线程或者其他有限的资源。在采用 JDBC 连接时的另一个不利影响是，数据库可能存在许多等待访问的阻塞线程。这种情况最终将导致整个 web 容器的线程不足和服务质量下降。
为了克服上述缺点，Servlet 3.0 添加了对挂起和恢复请求处理的支持，使 servlet 以异步、非阻塞的方式响应请求（这就是编程的 Comet 样式）。当一项请求被挂起时，处理请求的线程将在不生成任何响应的情况下返回给容器并准备执行其他任务。处理请求的 resume 方法恢复请求处理。只要当所请求的资源可用时，处理事件的线程才恢复被挂起的请并进行处理以生成响应。以下列举的是异步 servlets 的一些功能：
● 即使数据到达缓慢（非阻塞输入），也能在没有阻塞事件的情况下从客户机接收数据。
● 即使客户机或者网络运行缓慢（非阻塞输出），也能在不发生阻塞的情况下向客户机发送数据。
● 能处理被延迟的请求。如果在响应请求前必须获得远程/缓慢的资源，或者如果需要抑制访问特定的资源以防止过多的同步访问，对被延迟事件的处理是非常有用的。
● 能处理被延迟的响应关闭；也就是响应将保持打开以允许在发生异步事件时发送其他数据。
● 能通知阻塞或者非阻塞事件。
将新的 API 添加到 ServletRequest 和 ServletResponse，用于挂起、恢复和查询请求的状况、启用禁用和查询响应的状况。开发人员可以分别通过 requestSuspended(), requestResumed() 和 requestCompleted() 方法使用请求的 resume、suspend 和 complete 方法通知事件。有关这些方法的详细信息请参阅 Servlet 3.0 API。涉及使用异步 servlets 从远程 web 服务获取数据的事件顺序在图 1 中进行了图解说明。
Request handling using asynchronous servlet
图 1. 使用异步 servlet 处理请求
安全性
在 3.0 规范的早期草案中没有考虑安全性问题，因为专家团仍未就此问题达成一致。不过，方案建议提供通过编程实现登录和注销功能。HTTPServletRequest 中添加的新 API 可以启用这项功能。HTTPServletRequest 的 login 方法使应用程序或者框架强制进行以容器为中介的验证。HTTPServletRequest 和 HTTPSession 的 logout 方法允许应用程序重置请求的验证状态。
其他杂项变化
下面列举了一些为简化数据检索和简化应用程序开发而进行的功能增强。
HttpOnly Cookie：Servlet 3.0 规范允许将 cookie 标记为 HttpOnly cookie。由于向客户端脚本代码公开了 HttpOnly cookie，因而防止了某些种类的跨站点脚本攻击。大多数现代浏览器支持该项功能。以下列举了添加到 Cookie 类中以支持 HTTPOnly cookie 的方法：
void setHttpOnly(boolean isHttpOnly)
boolean isHttpOnly()
API 的变化： 将以下新增方法添加到 ServletRequest 中，以便轻松获得与请求对象相关的 ServletResponse 和 ServletContext 实例。
ServletResponse getServletResponse()
ServletContext getServletContext()
路线图
3.0 规范的早期草案于 2008 年 6 月完成了审查。由于 Servlet 3.0 的目标是用于 Java EE 6 平台或者更高版本，因此该规范推荐的最终发行版也与 Java EE 6 的发行版匹配。但是，规范的早期测试版本将通过 GlassFish 来提供，后者是 Java EE 的参考实现。预计 Servlet 3.0 的参考实现将被整合到 GlassFish 的版本 3 中。
JSR 草案在审查过程中确定了一些变化，正在编制的新方案将处理来自社区的建议和反馈意见。新方案中的主要变化如下：
● @Servlet 被重新命名为 @WebServlet，而 @ServletContextListener 被重新命名为 @WebServletContextListener.
● 新方案建议 @WebServlet 必须扩展 HTTPServlet 类。因此，如前所述，servlet 类可以不是 POJO 类。
● 类似地，@ServletFilter 类和 @WebServletContextListener 类需要分别实现 Filter 和 ServletContextListener 接口。
● 为启用和禁用 Servlet 提供选项。
结束语
在本文中，我们讨论了在 Servlet 3.0 的早期草案规范中提出的激动人心的特性。该规范已经开始在社区引起强烈反响。通过注释机制而实现的开发简易性、零配置使用框架和库、异步 servlets、可插拔性、安全性以及更多新增功能都是 Java Servlets 期待已久的特性。这说明，一些已经阅读了该规范的人表达了对注释过度使用、在扫描 web 片段时的安全威胁等问题的关注。但是，毫无疑问，Java Servlet 3.0 将使 servlet 开发人员的工作更轻松，并为开发下一代 web 应用程序提供了更多的支持。