InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

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

作者 Charles Humble 译者 刘一鸣 发布于 2009年6月12日

领域
语言 & 开发,
过程 & 实践
主题
Java ,
社区 ,
JCP标准
标签
Servlet ,
社区 ,
Java EE

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

千呼万唤 发表人 jiang rosen 发表于
  1. 返回顶部

    千呼万唤

    发表人 jiang rosen

    年初就应该出来了。

深度内容

大规模视频网站的计费与流量管理

本次分享将会就大规模视频网站的计费与流量管理这个话题,从操作层面细细进行讲解和分析,为系统工程师们揭示平日里我们没有关心的另一些内容。同时也希望本次分享能揭示行业中的一些“潜规则”,让互联网行业的流量与带宽管理更为开放与简洁。
本次演讲视频录制于QCon杭州2011

专访Jeffrey Richter:Windows 8是微软的重中之重

Jeffrey Richter以其多本Windows核心技术的经典著作而闻名,同时,他深入掌握微软的.NET等一系列核心技术,2012年1月,Jeffrey Richter在北京接受了InfoQ中文站的专访,谈到Windows 8和WinRT编程,并就异步编程、Windows编程中的可扩展性、性能和安全性方面给出自己的建议。

应用云平台的可用性——从新浪SAE看云平台设计

云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。

JVM定制改进 @ 淘宝

淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011

"伤得起"的云计算应用——对云端应用之架构的思考

2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。

让交付的速度跟上思考的速度

12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011

架构之路——穿行在产品和业务之间

篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011

特性注入:成功三部曲

本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。