BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News IBM Releases Open Liberty 18.0.0.4 with Support for MicroProfile 2.1 and Reactive Extensions

IBM Releases Open Liberty 18.0.0.4 with Support for MicroProfile 2.1 and Reactive Extensions

Bookmarks

IBM's fourth quarter 2018 release of Open Liberty 18.0.0.4 features full support for MicroProfile 2.1, reactive extensions, and connection pool metrics. As stated in the release:

Open Liberty now has reactive extensions to JAX-RS 2.1 so that you can use providers from Apache CXF and Jersey. And, on the ops side, there are connection pool metrics available from the Liberty runtime which you can now access from the /metrics endpoint that is provided by the MicroProfile Metrics feature.

First introduced in September 2017, Open Liberty is an open-source implementation of IBM's WebSphere Liberty application server to build microservices and cloud-native applications. Open Liberty's ongoing support for MicroProfile has ensured the latest version is included in its quarterly releases. This is evident with a brief look at Open Liberty's release history:

  • September 2017: 17.0.0.3 - MicroProfile 1.2
  • December 2017: 17.0.0.4 - Implementation of JSF
  • March 2018: 18.0.0.3 - MicroProfile 1.3
  • June 2018: 18.0.0.2 - Java EE 8
  • September 2018: 18.0.0.3 - MicroProfile 1.4 and MicroProfile 2.0
  • December 2018: 18.0.0.4 - MicroProfile 2.1

MicroProfile 2.1

Open Tracing 1.2 was the only updated API in MicroProfile 2.1 released on October 19, 2018. New and improved features included: allow for more targeted tracing results; more easily correlate tracing requests with an application's URL; skip the tracing of JAX-RS requests; the use of an alternate format for Open Tracing span names; and the addition of new MicroProfile Config 1.3 API keys that enable new Open Tracing functions.

JAX-RS requests may be excluded from tracing by specifying a regular expression, defined in a new configuration key, mp.opentracing.server.skip-pattern, that matches UriInfo.getPath(). The regular expression must comply with java.util.regex.Pattern. IBM's Knowledge Center on Open Tracing defines why tracing on JAX-RS request could be excluded:

Server-side tracing can be excluded by specifying a skip pattern. You might want to exclude some trace information so that you get tracing for specific things. In that case, you might choose to exclude server-side tracing to reduce the number of spans that are created.

For Open Tracing span names, the new alternate format is:

    
<http method>:/<endpoint>/<endpoint method>
    

As shown in Open Liberty's Open Tracing guide, an example of this is:

    
GET:/inventory/list
    

More details may be found in the the Open Tracing specification.

Reactive Extensions to JAX-RS

With Open Liberty 18.0.0.4, reactive extensions to the JAX-RS (JSR-370) are possible with providers such as Apache CXF and Jersey. In a recently Open Liberty blog, Andy McCright, web services architect at IBM, recently discussed what's new with REST in Open Liberty:

JAX-RS 2.1 introduced the reactive client, but the spec only requires vendors to implement it using Java 8's CompletionStage API. Other reactive frameworks can integrate with the reactive client, but that is optional in the spec. With Liberty 18.0.0.4, it is now possible to use these extensions. We've tested with RxJava 1 and 2 using providers from Apache CXF and Jersey, and we plan to test more.

Kevin Sutter, MicroProfile and Jakarta EE (EE4J) architect for WebSphere at IBM, spoke to InfoQ about this latest release and what we can expect from Open Liberty in 2019.

InfoQ: Have there been challenges in providing full support for a current version of MicroProfile in an upcoming Open Liberty release?

Kevin Sutter: Open Liberty has had a history of providing a fully-supported, production-ready implementation of the MicroProfile specifications within three months of being released by the Eclipse MicroProfile project. We laid this out as a goal since day one of the project and we've had fun keeping to that schedule. Has it been challenging? Sure. But, it's been a large team effort and that makes it more doable. We participate in every MicroProfile specification. Some of them we lead, some of them we just participate. But, we do engage on every specification. That gives us an edge because we're already in tune with the requirements of the various specifications.

In most cases, we are implementing the specification as the wider MicroProfile team is continuing to define it. And, in some cases, we deliver early versions of the implementations via our monthly Liberty Betas. The feedback from those Betas also can be fed back into the development of the specification. All of this preliminary work is beneficial to our goal of providing timely MicroProfile implementations.

One of the requirements of releasing a MicroProfile specification is to have an open-source "compatible implementation." This compatible implementation doesn't have to be a final release or production-ready. But, it does have to demonstrate that the specification is implementable and that the TCK executes successfully against it. Also, it does have to be available, buildable, and testable via some public open-source repository (i.e., GitHub).

For most of the MicroProfile specifications that we lead, we develop the compatible implementation in Open Liberty. One exception is that we lead the MicroProfile Rest Client project, but the compatible implementation is Apache CXF. But, since Apache CXF is the basis for Open Liberty's JAX-RS implementation, indirectly we're still developing in Open Liberty.

In any case, these compatible implementations are not meant to be the final release. We still have additional work to ensure that these implementations are production-ready and fully supported. But, we have a great headstart on getting them included in the next release of Open Liberty.

InfoQ: What's on the horizon for Open Liberty in 2019?

Sutter: One major improvement we're doing in 2019 is to go with a four-week release cycle (instead of the quarterly releases we did the last couple of years). This compressed release cycle presents some new challenges to our MicroProfile development efforts. As you know, MicroProfile produces several releases per year.

Last year, MicroProfile produced three platform releases (including support for Java EE 8). This year, the plan is to provide three more platform releases in February, June, and October. In the past, we would target the support for each of these MicroProfile releases in the next quarterly release of Open Liberty. But, with these four week release cycles, the "next Open Liberty release" is probably not doable.

So, our new goal is to allow for two (2) two-week development iterations after MicroProfile provides their platform release. This actually crunches down our previous goal of providing an implementation within a quarter (12 weeks) down to about eight weeks. We'll see if can keep up with this. But, following our agile processes, we will only release the capability when it's ready -- fully tested, production-ready, and fully supported.

InfoQ: What are your current responsibilities, that is, what do you do on a day-to-day basis?

Sutter: My main responsibilities are to shepherd the overall development of MicroProfile, Jakarta EE, and Java EE for the Hybrid Cloud organization. That's my "IBM job." Externally, I am very active with the MicroProfile community as co-lead of the Eclipse project. I participate on some of the Component specifications, but my main focus is to ensure a smooth platform delivery. I am also participating on the Jakarta EE Steering and Specification committees. This has been a challenging effort as we move the Java EE artifacts and processes into the Eclipse environment -- keeping the good things and removing the not-so-good.

I also stay involved with the day-to-day activities of the EE4J efforts as a member of the PMC and the Platform project. The most recent activity in this area is finalizing the Java EE 8 compatibility testing for Eclipse Glassfish. The next steps will involve the release of Jakarta EE 8 and planning for its future.

Resources

Rate this Article

Adoption
Style

BT