@levinzhang
2016-08-10T21:57:33.000000Z
字数 3040
阅读 533
by Charles Humble on Aug 04, 2016
在拉斯维加斯举行的SpringOne平台会议上,Mark Thomas(markt@apache.org)给出了Apache Tomcat最新的路线图。我们之前曾经关注过Java EE 8的延期,他指出这件事情同样给Apache Tomcat团队带来了不少的问题。
在拉斯维加斯举行的SpringOne平台会议上,Mark Thomas(markt@apache.org)给出了Apache Tomcat最新的路线图。我们在InfoQ上曾经关注过Java EE 8的延期,他指出这件事情同样给Apache Tomcat团队带来了不少的问题。
Thomas是Pivotal的咨询软件工程师,从2003年开始就是Apache Tomcat的提交者。他强调,这个演讲阐述的是有关Tomcat未来的个人观点,并不代表Apache软件基金会或Pivotal的观点。
关于路线图,Tomcat 9将会添加对Servlet 4.0的支持。Thomas说到,“这其实可以分为三类:专家组已经广泛同意的内容、目前正在工作中的内容以及一些将来可能的规划。”
在Servlet 4.0已经获得同意的元素方面,将会包含对HTTP/2的支持,但是Thomas指出,“应用程序本身并不会看到这个特性,应用本身唯一与HTTP/2能够产生关联的地方就是推送请求。”这项特性的API已经获得了专家组的同意,在Tomcat 9中已经实现了。
Servlet 4.0同时还为监听器(listener)增加了一些默认的NO-OP方法,从而减少了我们需要编写的样板式代码。类似的,还引入了HttpFilter的抽象基础类,它的功能非常类似于HttpServlet。Thomas说“通过它,我们可以在过滤器中直接使用HttpServletRequest和HttpServletResponse,而不必再使用ServletRequest、ServletResponse以及额外的类型转换。”
正在讨论的内容包括如何将一个请求映射到当前的Servlet上——也就是说,如果它的映射方式使用的是扩展名映射、路径映射和/或URL中的一部分,那实际上是映射到一个通配符上。这是JSF专家组要求了很久的特性,他们所提议的API已经在Tomcat中实现了,不过有一些微调,目前正在Jetty中进行实现。但是,它还没有获得Servlet 4.0专家组的同意。
另外两个正在讨论的事情是对请求参数的非阻塞访问,这个特性类似于已经实现的非阻塞读取请求体,它会提供一种机制,允许开发人员以非阻塞的方式从请求体中读取参数;还有对反应型(reactive)的支持,它会是Spring 5的一个主题。
Spring和Jetty的工作人员已经开始讨论在Servlet容器中实现对反应型的支持。这有望将Tomcat社区包含进来,目标是创建一个Jetty和Tomcat共享的标准API,应用程序可以使用这个API。如果专家组能够确定,希望将其添加到Servlet 4.0中的话,那么这会是一个很好的起点模型,实现Servlet 4.0对反应型API的支持。
不过,除此之外,专家组缺乏进展成为了很明显的问题。Thomas说,对于Tomcat支持的其他规范——JSP、统一表达式语言(Unified Expression Language)、JASPIC(针对容器的Java认证服务提供者——实际上是一个可插拔的认证提供者)以及WebSocket——“则是完全没有任何进展”。
如果说关于Java EE 8目前有什么清晰指示的话,那这就是现状了,他们保持了完全的沉默。
JASPIC至少大致比较稳定和完整。问题更多的是JSP和统一表达式语言规范,因为统一表达式语言 3增加很多新特性,它会影响到JSP,但是JSP并没有进行更新以考虑这些新特性。
一个简单的样例就是在统一表达式语言中,我们现在可以导入类。如果在JSP页面中的一段表达式语言里面这样做的话,那么我们所导入的类是否要对这个JSP页面可见呢?在Tomcat中是这样的,但是关于是否应该如此,规范方面则保持了完全的沉默。
更为重要的是WebSocket依然缺乏一个标准的API来编写扩展,比如压缩、多路复用等等。在要完成WebSocket 1.0的时候,就开始讨论这项功能,但是到现在为止依然没有明显的进展。
从历史上来看,Tomcat的主发布版本依赖于三项内容:稳定的相关规范、通过TCK验证的实现(尽管在Tomcat 8中,这一点并不成立),另外,Tomcat社区相信代码库足够稳定,可以用于生产环境运行。
在 Java EE 8中,我们所遇到的问题就是所有的事情都毫无进展。我们不知道规范何时能够最终完成。如果今年能够完成的话,我会非常惊讶,如果明年能够完成的话,我会感到非常惊喜,不过,它更有可能要拖到2018年才能完成……缺乏最终的规范给我们带来了很多的问题,因为Tomcat 9的大量功能已经准备就绪,我们大约在一年前就已经实现了对HTTP/2的支持。
在很大程度上,这就是我们引入Tomcat 8.5的原因所在。Tomcat 8.5中的一些新特性也会包含到Tomcat 9中,但它们并不是Java EE规范的一部分,其中包括对TLS支持的一个大范围修改。Tomcat 8.0允许每个连接器对应一个TLS虚拟主机,每个虚拟主机会有一个证书,Tomcat 8.5及以上支持每个连接器对应多个虚拟主机(通过SNI来实现的),每个主机能有多个证书。
不过,这里有个有意思的问题。Servlet 4.0必须运行在Java 8上并且必须要支持HTTP/2。HTTP/2需要用到ALPN(应用层协议协商,Application Layer Protocol Negotiation)和JSSE,在Java 8中,并不支持ALPN。
这就意味着我们无法以纯Java形式来实现符合该规范的Servlet 4.0容器,这是Tomcat团队在18个月前所遇到的问题。按照Thomas的说法,他们要求向下移植(back-port)ALPN,但是遭到了拒绝。
几周前,好像IBM的实现也到达了这个功能点,他们向专家组问了同样的问题。我怀疑他们会得到相同的解答。
因此,在目前的Tomcat中,ALPN需要OpenSSL来进行加密。Tomcat对OpenSSL进行了包装,使其看起来像一个JSSE的实现。
除了对JASPIC的支持以外,这包括针对Google OAuth 2的一个样例配置,Tomcat 8.5和9还支持虚拟主机名的通配符匹配、相对HTTP转发以及大量的其他特性。正在考虑支持的特性包括针对容器的Java授权协议(Authorisation Contract for Containers,JACC),这是一个与JASPIC相对应的授权功能。
也有一些特性被放弃了,包括BIO HTTP和BIO AJP连接器以及对Comet的支持,它们在很大程度上已经被WebSocket取代了。
尽管TomEE已经提供了对Web Profile的支持,但是Tomcat 9并没有实现Web Profile的计划。
InfoQ今年再次拍摄了SpringOne的所有演讲,在未来的几个月中,所有的视频都将会逐步放到我们的站点上。
查看英文原文:Impact of Java EE 8 Hiatus on Tomcat 9 Highlighted at SpringOne