Following on from the recent MicroProfile Config API and Fault Tolerance work in Liberty, we’ve now got a first look at MicroProfile Metrics. In addition, with all the exciting news about the future of Java EE, we figured we’d best get on with implementing some of the new Java EE 8 features. It’s early days yet so there are obviously limitations in what’s been implemented so far but please give them a try and let us know what you think.

Thanks to your support for our regular beta programme, we are able to release new production-ready Liberty features every few months. Most recently, in June. Look out for more betas over the coming months. WebSphere Liberty is built on the Open Liberty project. Find out more on the Open Liberty website and join the Open Liberty mailing list.

Get it now! Ask a question about the beta

What’s new in this release?

MicroProfile Metrics

MicroProfile Metrics provides a way for developers to instrument their microservices and applications that will be portable across all MicroProfile Metrics implementations. The API is similar to the Dropwizard Metrics API that many developers are already familiar with. Using MicroProfile Metrics avoids the need to find and include third-party metrics libraries and integrate those libraries with Liberty.

For operations teams, MicroProfile Metrics provides a consistent way to access metrics from their Liberty servers through a simple REST interface. The REST API can return output compatible with Prometheus or with any monitoring tools that can consume JSON.

Developers: In the beta, the microProfile-1.2 feature is enabled by default, which includes the mpMetrics-1.0 feature. But if you want only the mpMetrics-1.0 feature for some reason, here’s what you want in your server.xml:


To find out more, see the Knowledge Center: Adding metrics to applications

Ops: To enable the /metrics REST interface, add the following definition to your server.xml:

<quickStartSecurity userName="theUser" userPassword="thePassword"/>
<keyStore id="defaultKeyStore" password="Liberty"/>

Then verify that things are set up correctly by hitting https://yourserver:9443/metrics

To find out more, see the Knowledge Center: Monitoring the Liberty server runtime environment

New Java EE 8 features in this beta

Before you dive in, let’s get the limitations out of the way. The beta enables the microProfile-1.2 feature by default (this includes JAX-RS2.0, CDI 1.2, JSON-P 1.0, mpConfig-1.1, mpFaultTolerance-1.0, mpHealth-1.0, mpJwt-1.0, and mpMetrics-1.0). The new Java EE 8 features described in this section are currently not compatible with the microProfile-1.2 feature.

This means that to try any of the Java EE 8 features in this beta, you must add the relevant definition to the server.xml (see below for details) and you must remove the microProfile-1.2 definition from the server.xml to disable it.

Also note that the jaxrs-2.1 feature doesn’t currently work with servlet-4.0. What can I say? It’s a beta and there are limitations. It will get better. 🙂

Servlet 4.0

Servlet 4.0 is the latest Java EE 8 version of the Servlet specification. The beta includes the following new features and functions:

  • Support for HTTP/2 server push but not with ALPN (Application-Layer Protocol Negotiation) and not fully tested
  • Support for HTTP trailers
  • HttpServletRequest.getMapping()
  • ServletContext.getSessionTimeout() and setSessionTimeout()

To add Servlet 4.0 to your application, add this feature definition to your server.xml:


In this beta the servlet-4.0 feature can be used with other Java EE 7 features. When a full set of Java EE 8 features are available this may no longer be possible. The servlet-4.0 feature cannot currently be used with the jaxrs-2.1 feature.

JAX-RS 2.1

JAX-RS 2.1 enables two exciting new technologies: reactive client and server-sent events. The reactive client takes full advantage of Java 8 lambda expressions to enable highly scalable multi-threaded clients. Server-sent events allow developers to send data asynchronously to multiple clients, either individually or by broadcasting to all in an efficient manner.

Coding an asynchronous JAX-RS client was possible in JAX-RS 2.0 but the reactive client in 2.1 enables much more parallelism with much less code. Users can now kick off multiple client requests having each one react to the response from the server, potentially by making new asynchronous requests.

Server-sent events was not possible using JAX-RS APIs prior to 2.1. Users wishing to send updates to remote clients using JAX-RS would need to rely on polling which is inefficient. Otherwise, they would need to rely on third-party implementations to provide SSE or SSE-like functionality. Now a JAX-RS resource can allow multiple clients to register for events – then send them on a schedule, randomly, at the request of other clients, with very little code.

To enable JAX-RS 2.1, add the following definition to your server.xml:


The jaxrs-2.1 feature cannot currently be used with the servlet-4.0 feature.

JavaServer Faces (JSF) 2.3

Application developers can take advantage of the latest JSF features and enhancements. The jsf-2.3 feature pulls in the Apache MyFaces implementation and integrates it into the Liberty runtime. The following features of JSF 2.3 have been tested and are available for use:

  • <f:importConstants/>
  • Enhanced component search facility
  • DataModel implementions can be registered
  • CDI replacement for @ManagedProperty
  • UIData and <ui:repeat> support for Map and Iterable
  • <ui:repeat> condition check
  • Java Time support
  • WebSocket integration with <f:websocket>
  • Multi-field validation with <f:validateWholeBean>. The disabled attribute does not currently function.
  • Use CDI for the evaluation of JSF-specific expression language (EL) implicit objects. Currently, implicit objects are only supported using CDI.
  • Support @Inject on JSF-specific artifacts: Injection can now be done within a class annotated with FacesValidator, FacesConverter, and FacesBehavior.

To enable the JSF 2.3 feature just add the following feature definition to your server.xml:


To use CDI, currently, you must enable the cdi-1.2 feature along with the jsf-2.3 feature in your server.xml. When a Java EE 8 CDI feature is available you will be required to use the Java EE 8 version instead of the Java EE 7 version.


HTTP/2.0 support allows for optimization of HTTP traffic between two endpoints using a full-duplex connection and multiple parallel HTTP streams (effectively Request/Response sequences) over one underlying TCP/IP connection.

This beta contains HTTP/2.0 support over a plain text connection. The Liberty server recognizes an HTTP Get or Post request with an HTTP Header of type Upgrade with a value of h2c, in accordance with RFC 7540. The Liberty server will then adhere to the HTTP/2.0 protocol for the connection. All HTTP/2 frames will be processed according to RFC 7540. The frame types being: DATA, HEADERS, PRIORITY, RST_STREAM, SETTINGS, PUSH_PROMISE, PING, GOAWAY, WINDOW_UPDATE, CONTINUATION.

Push Promise capability will be supplied via the Servlet 4.0 APIs or via an HTTP Link Header (RFC 5988) with a link type of preload.

Enabling distributed tracing

The opentracing-1.0 feature, together with a user provided io.opentracing.Tracer implementation, enables JAX-RS applications to automatically create, propagate, and deliver distributed tracing information.

In an environment with numerous services communicating with each other, distributed trace information provides a way to view the end-to-end flow of requests through multiple services. In many environments, there is a central trace collection service that accepts distributed tracing information from individual applications (one popular distributed tracing service is Zipkin). The central service correlates the distributed tracing information, and presents the end-to-end request flow information with a UI.

The project defines an API that applications can use to create, propagate, and deliver distributed trace information. An implementation of the API must be available to an application so that the application can deliver distributed trace information. The implementation of the API must match the implementation of the central trace collection service. For example, if the central trace collection service is Zipkin, then the implementation used by applications must perform distributed tracing functions in a way that is specific to Zipkin.

Typically, the developer of each application in the environment must explicitly add code to the application in order for it to create, propagate, and deliver distributed tracing information. With the opentracing-1.0 feature of Liberty, developers do not need to add any code to their JAX-RS applications to participate in distributed tracing. The JAX-RS application will automatically create, propagate, and deliver distributed tracing information.

Each Liberty server in the environment must be configured with a user feature that provides an implementation of the API. The user feature must provide an implementation of the API that matches the central trace collection service that is used in the environment.

You can find sample source code for a user feature that provides a Zipkin-specific API implementation on GitHub. Or you can download a built version of the user feature from Maven Central.

What’s already in there?

The Aug/Sept Liberty beta included updates to the MicroProfile Config and Fault Tolerance features.

Take a look at the previous beta announcements for a full list of stuff added since the release in June 2017:

Get it now! Ask a question on Stack Overflow

Join The Discussion

Your email address will not be published. Required fields are marked *