IBM发布Open Liberty 18.0.0.4，支持MicroProfile 2.1和反应性扩展框架

IBM在2018年第四季度发布的Open Liberty 18.0.0.4提供了对MicroProfile 2.1、反应性扩展框架和连接池指标的全面支持。根据发布说明：

Open Liberty现在对JAX-RS 2.1进行了反应性扩展，这样你就可以使用来自Apache CXF和Jersey的提供程序。在ops方面，Liberty运行时提供了一些连接池指标，现在，你可以从MicroProfile Metrics特性提供的/metrics端点访问这些指标。

Open Liberty于2017年9月首次推出，是IBM WebSphere Liberty应用服务器的开源实现，用于构建微服务和原生云应用程序。Open Liberty对MicroProfile的持续支持确保了最新版本包含在季度发行版中。简单看一下Open Liberty的发行历史就能明白这一点：

2017年9月：17.0.0.3 —— MicroProfile 1.2
2017年12月：17.0.0.4 —— JSF实现
2018年3月： 18.0.0.3 —— MicroProfile 1.3
2018年6月： 18.0.0.2 —— Java EE 8
2018年9月： 18.0.0.3 —— MicroProfile 1.4和MicroProfile 2.0
2018年12月： 18.0.0.4 —— MicroProfile 2.1

MicroProfile 2.1

Open tracking 1.2是MicroProfile 2.1中唯一更新的API，于2018年10月19日发布。新特性及改进特性包括：允许更有针对性的跟踪结果；更容易将跟踪请求与应用程序的URL关联起来；跳过JAX-RS请求跟踪；使用另一种Open Tracing Span名称格式；添加了新的MicroProfile Config 1.3 API键，支持新的Open Tracing函数。

JAX-RS请求可以通过指定一个与UriInfo.getPath()相匹配的正则表达式排除在跟踪之外，该正则表达式定义在一个新增的配置键mp.opentracing.server.skip-pattern中。正则表达式必须符合java.util.regex.Pattern。IBM Open Tracing知识中心详细说明了为什么排除JAX-RS请求跟踪：

可以通过指定跳过模式排除服务器端跟踪。你可能希望排除一些跟踪信息，以便跟踪特定的东西。在这种情况下，你可以选择排除服务器端跟踪，以减少所创建的Span数量。

新增的Open Tracing Span名称替代格式如下：

\u0026lt;http method\u0026gt;:/\u0026lt;endpoint\u0026gt;/\u0026lt;endpoint method\u0026gt;

如Open Liberty Open Tracing指南所示，下面是该格式的一个示例：

GET:/inventory/list

要了解更多细节，请查看Open Tracing规范。

JAX-RS的反应性扩展

使用Open Liberty 18.0.0.4，可以通过Apache CXF和Jersey等提供程序对JAX-RS（JSR-370）进行反应性扩展。在Open Liberty博客中，IBM Web服务架构师Andy McCright最近讨论了Open Liberty中的REST新特性：

JAX-RS 2.1引入了反应性客户端，但是规范只要求供应商使用Java 8的CompletionStage API实现它。其他反应性框架框架可以与反应性框架客户端集成，但在规范中这是可选的。借助Liberty 18.0.0.4，我们现在可以使用这些扩展。我们已经使用来自Apache CXF和Jersey的提供程序对RxJava 1和2进行了测试，我们计划进行更多测试。

IBM WebSphere MicroProfile和Jakarta EE（EE4J）架构师Kevin Sutter向InfoQ介绍了这个最新版本，以及2019年关于Open Liberty的计划。

InfoQ：在即将发布的Open Liberty版本中，为MicroProfile的当前版本提供全面支持是否遇到了挑战？

Kevin Sutter：Open Liberty曾经在Eclipse MicroProfile项目发布后的三个月内提供了完全支持的、可用于生产的MicroProfile规范实现。从项目的第一天起，我们就把这作为一个目标，并且我们很高兴能够遵守这个时间表。这有挑战性吗？当然。但是，这是一项大型的团队工作，这样更可行。我们参与每一项MicroProfile规范。有些是我们负责的，有些我们只是参与。但是，我们确实参与每一项规范。这给了我们一个优势，因为我们已经熟悉了各种规范的要求。在大多数情况下，在更广泛的MicroProfile团队正在继续定义它的时候，我们正在实现规范。在某些情况下，我们通过每月的Liberty Beta交付早期版本的实现。这些Beta版的反馈也可以反馈到规范的开发中。所有这些前期工作都有助于我们及时实现MicroProfile的目标。
MicroProfile规范发布的其中一个要求是有一个开源的“兼容实现”。这个兼容的实现不一定是最终的版本或产品。但是，它必须证明规范是可实现的，并且TCK在上面成功执行。此外，它必须可用、可构建，并且可以通过一些公共的开源存储库进行测试（如GitHub）。对于我们负责的大多数MicroProfile规范，我们在Open Liberty中开发兼容实现。一个例外是我们负责的MicroProfile Rest客户端项目，其兼容实现是Apache CXF。但是，由于Apache CXF是Open Liberty JAX-RS实现的基础，因此，我们仍然间接地在Open Liberty中进行开发。无论如何，这些兼容实现并不是最终的版本。我们还有额外的工作要做，以确保这些实现是生产就绪的，并且得到完全支持。但是，为把它们加入Open Liberty的下一个发行版中，我们有了一个很好的开端。

InfoQ：关于Open Liberty，2019年有什么计划？

Sutter：我们在2019年所做的一个主要改进是采用四周一次的发布周期（而不是过去几年的季度发布）。压缩后的发布周期对我们的MicroProfile开发工作提出了一些新的挑战。如你所知，MicroProfile每年都会发布几个版本。去年，MicroProfile发布了三个平台版本（包括对Java EE 8的支持）。今年的计划是在2月、6月和10月再发布三个平台版本。过去，我们的目标是在下一个季度的Open Liberty中支持这些MicroProfile版本。但是，在四周一次的发布周期中，“下一个Open Liberty版本”可能无法实现。因此，我们的新目标是在MicroProfile提供其平台版本之后进行两个为期两周的开发迭代。这实际上把我们之前在一个季度（12周）内提供实现的目标压缩到了大约8周。我们看看能不能跟上。但是，按照我们的敏捷流程，我们只会在功能准备就绪时发布它——完全测试、生产就绪和完全支持。

InfoQ：您目前负责什么，也就是说，您每天都做些什么？

Sutter：我的主要职责是为混合云组织的MicroProfile、Jakarta EE和Java EE总体开发提供指导。这就是我在“IBM的工作”。在外部，我非常积极地与MicroProfile社区合作，共同领导Eclipse项目。我参与了一些组件规范，但我的主要关注点是确保平台交付的顺利进行。我还参加了Jakarta EE指导和规范委员会。将Java EE工件和流程移到Eclipse环境中是一项具有挑战性的工作——保留好东西，删除不好的东西。作为PMC和平台项目的一员，我还参与了EE4J工作的日常活动。这方面的最新活动是完成Eclipse Glassfish的Java EE 8兼容性测试。下一步工作涉及Jakarta EE 8的发布及其未来规划。