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.
What’s new in this release?
- MicroProfile Metrics
- New Java EE 8 features:
- HTTP/2.0 support
- Distributed tracing
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
<featureManager> <feature>mpMetrics-1.0</feature> </featureManager>
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
<featureManager> <feature>mpMetrics-1.0</feature> </featureManager> <quickStartSecurity userName="theUser" userPassword="thePassword"/> <keyStore id="defaultKeyStore" password="Liberty"/>
Then verify that things are set up correctly by hitting
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,
mpMetrics-1.0). The new Java EE 8 features described in this section are currently not compatible with the
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 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
To add Servlet 4.0 to your application, add this feature definition to your
<featureManager> <feature>servlet-4.0</feature> </featureManager>
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
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
<featureManager> <feature>jaxrs-2.1</feature> </featureManager>
jaxrs-2.1 feature cannot currently be used with the
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:
- Enhanced component search facility
- DataModel implementions can be registered
- CDI replacement for
<ui:repeat>support for Map and Iterable
- Java Time support
- WebSocket integration with
- Multi-field validation with
disabledattribute 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.
@Injecton JSF-specific artifacts: Injection can now be done within a class annotated with
To enable the JSF 2.3 feature just add the following feature definition to your
<featureManager> <feature>jsf-2.3</feature> </featureManager>
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:
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
Enabling distributed tracing
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 opentracing.io project defines an API that applications can use to create, propagate, and deliver distributed trace information. An implementation of the opentracing.io API must be available to an application so that the application can deliver distributed trace information. The implementation of the opentracing.io API must match the implementation of the central trace collection service. For example, if the central trace collection service is Zipkin, then the opentracing.io 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 opentracing.io API. The user feature must provide an implementation of the opentracing.io 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 opentracing.io 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 18.104.22.168 release in June 2017: