转载

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 名称替代格式如下：

 复制代码

<httpmethod>:/<endpoint>/<endpointmethod>

如 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 的发布及其未来规划。

原文 https://www.infoq.cn/article/3DtvON*YhBRjN0NuBDW0

正文到此结束