New features for MicroProfile 4.0 and more Jakarta EE 9 features in Open Liberty 20.0.0.10 beta

Jakub Pomykala on Sep 2, 2020

announcements , microprofile , beta , jakarta-ee ,

Post available in languages:

In this release of Open Liberty Beta you can try the new features for MicroProfile 4.0 which are Fault Tolerance 3.0, Metrics 3.0, Health 3.0 and OpenTracing 2.0 plus more Jakarta EE 9 features.

We have two beta packages for Open Liberty:

All Beta Features: a new, larger package that contains all Open Liberty beta features (including Jakarta EE 9 beta features) and GA features and functions.
Jakarta EE 9 Beta Features: a lightweight package that contains only the Jakarta EE 9 features.

This means that you can now try out our in-development Open Liberty features by just adding the relevant coordinates to your build tools (either the All Beta Features package or the Jakarta EE 9 Beta Features package, depending on what you want to try).

If you try either package, let us know what you think.

All Beta Features package

The All Beta Features package includes the following beta features:

MicroProfile Fault Tolerance 3.0
MicroProfile Metrics 3.0
MicroProfile Health 3.0
MicroProfile OpenTracing 2.0
Jakarta EE 9 Beta Features package

MicroProfile Fault Tolerance 3.0

MicroProfile Fault Tolerance allows you to easily apply strategies for mitigating failure to their code. It provides annotations which you can add to methods to use bulkhead, circuit breaker, retry, timeout and fallback strategies.

Fault Tolerance 3.0 overhauls the metrics that are automatically exported by Fault Tolerance to take advantage of tags and make it easier to use those metrics to understand when and where your application is failing.

Information which was previously included in the metric name is now included as metric tags, making it much easier to query for data from multiple methods and pick out which, if any, is causing issues.

Example:

Old metric: application:ft.<name>.timeout.callsTimedOut.total

New metric: base:ft.timeout.calls.total{method="<name>", timedOut="true"}`

Try it now

Enable Fault Tolerance 3.0 and CDI in the server.xml, along with any other features you’re using.

<featureManager>
  <feature>mpFaultTolerance-3.0</feature>
  <feature>cdi-2.0</feature>
  <feature>jaxrs-2.1</feature>
</featureManager>

Add any of the Fault Tolerance annotations to a business method of a CDI bean.

@Retry(5)
public User lookupUserFromRegistry(String name) {
  return registry.getUser(name);
}

When that method is called as a a CDI business method, the fault tolerance strategy will be used. In this example, if lookupUserFromRegistry() would throw an exception, it will instead be retried up to five times.

Get an introduction to MicroProfile Fault Tolerance with the Open Liberty guides Failing fast and recovering from errors and Preventing repeated failed calls to microservices.

For more information:

MicroProfile Metrics 3.0

MicroProfile Metrics 3.0 (as part of MicroProfile 4.0) introduces new metric values for the existing SimpleTimer and Timer metrics. Additionally a new REST metric is introduced for better monitoring and handling of unmapped exceptions. Manual configuration for re-usability has been removed. A notable change to the MicroProfile Metrics programming model regarding CDI Producers has been made. Lastly a medley of API improvements and refactoring have been added in this release.

SimpleTimer

The SimpleTimer metric now tracks and reports the highest and lowest recorded time duration of the previous complete minute. See SimpleTimer Javadoc for more information.

Timer

The Time metric now tracks and reports the total elapsed time duration. See Timer Javadoc for more information.

REST metric

A new REST.request.unmappedException.total metric that is backed by a counter metric has been introduced. Similar to the REST.request metric, there will be one unique metric for each REST endpoint identified by a class and method label. The new REST metric will count the amount of times the request ends in an unmapped exception. The REST.request metric corresponding to this REST endpoint will not record any values if an unmapped exception has occured.

CDI Producer

The @Metrics annotation will no longer support the method target (i.e it can not be annotated on a method). Additionally, it will not support usage with CDI Producers.

Try it now

Enable Metrics 3.0 in the server.xml, along with any other features you’re using.

<featureManager>
    <feature>mpMetrics-3.0</feature>
</featureManager>

More information:

MicroProfile Health 3.0

MicroProfile Health 3.0 enables you to provide your own health check procedures to be invoked by Open Liberty, to verify the health of your microservice.

MicroProfile Health allows services to report their health, and it publishes the overall health status to a defined endpoint. A service reports UP if it is available and reports DOWN if it is unavailable. MicroProfile Health reports an individual service status at the endpoint and indicates the overall status as UP if all the services are UP. A service orchestrator can then use the health statuses to make decisions.

MicroProfile Health checks its own health by performing necessary self-checks and then reports its overall status by implementing the API provided by MicroProfile Health. A self-check can be a check on anything that the service needs, such as a dependency, a successful connection to an endpoint, a system property, a database connection, or the availability of required resources. MicroProfile offers checks for both liveness and readiness.

In the mpHealth-3.0 feature for Open Liberty:

The overall default Readiness status was changed to DOWN, with an empty response until all the deployed application(s) have been started. A new MicroProfile Config property (mp.health.default.readiness.empty.response=UP) is introduced to change the overall default Readiness check status to UP, during application start up, that do not have any user-defined health checks.
The HealthCheckResponseBuilder.state(Boolean UP) method was also renamed to HealthCheckResponseBuilder.status(Boolean UP) for HealthCheckResponse deserialization compatibility, where the JSON health check response string can now be deserialized into an HealthCheckResponse object.
The deprecated @Health qualifier was removed, and you should use the @Liveness or @Readiness qualifiers in your HealthCheck implementations, as appropriate.

Applications are expected to provide health check procedures by implementing the HealthCheck interface with the @Liveness or @Readiness annotations. These are used by Open Liberty to verify the Liveness or Readiness of the application, respectively. Add the logic of your health check in the call() method, and return the HealthCheckResponse object, by using the simple up()/down() methods from the API:

**Liveness Check**
@Liveness
@ApplicationScoped
public class AppLiveCheck implements HealthCheck {
...
    @Override
     public HealthCheckResponse call() {
       ...
       HealthCheckResponse.up("my-liveness-check");
       ...
     }
}

**Readiness Check**
@Readiness
@ApplicationScoped
public class AppReadyCheck implements HealthCheck {
...
    @Override
     public HealthCheckResponse call() {
       ...
       HealthCheckResponse.named("my-app-readiness").status(isMyAppReady()).build();
       ...
     }
}
...

To view the status of each health check, access the either the http://<hostname>:<port>/health/live or http://<hostname>:<port>/health/ready endpoints.

More information:

MicroProfile OpenTracing 2.0

MicroProfile OpenTracing 2.0 can be used to profile and monitor applications built using microservice architecture.

MicroProfile OpenTracing 2.0 has upgraded the OpenTracing API to version 0.33.0. This allows the use of tracing backends and their libraries that are built on OpenTracing API 0.33.0.

Try it now

Include the following in the server.xml:

    <feature>mpOpenTracing-2.0</feature>

Also configure a tracing backend such as Jaeger or Zipkin.
For Jaeger, add the following maven dependencies in the application’s pom.xml.

<dependency>
    <groupId>io.jaegertracing</groupId>
    <artifactId>jaeger-client</artifactId>
    <version>1.2.0</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-api</artifactId>
    <version>1.7.30</version>
</dependency>
<dependency>
    <groupId>org.slf4j</groupId>
    <artifactId>slf4j-jdk14</artifactId>
    <version>1.7.30</version>
</dependency>

You can find out more about about configuring Jaeger settings using environment variables by looking at jaeger-client-java readme.

For the JAEGER_PASSWORD environment variable, the password can be encoded using the securityUtility command.

Depending on Jaeger’s sampling settings JAEGER_SAMPLER_TYPE and JAEGER_SAMPLER_PARAM, Jaeger may not report every span created by the applications.

For Zipkin, take a look at the sample project to see how to implement a tracer for Liberty.

Define your application in the server.xml:

<webApplication location="yourapp.war" contextRoot="/yourapp">
    <!-- enable visibility to third party APIs -->
    <classloader apiTypeVisibility="+third-party" />
</webApplication>

Once you have hit some JAX-RS endpoints of your application, you should be able to find spans in the user interface of your tracing backend.

More information:

Try it now

To try out these features, just update your build tools to pull the Open Liberty All Beta Features package instead of the main release. The beta works with Java SE 14, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
  <groupId>io.openliberty.beta</groupId>
  <artifactId>openliberty-runtime</artifactId>
  <version>20.0.0.10-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-runtime', version: '[20.0.0.10-beta,)'
}

Or take a look at our Downloads page.

Jakarta EE 9 Beta Features package

The main change visible to developers in the Jakarta EE 9 planned release is the names of packages changing to accomodate the new jakarta.* namespace. In this Open Liberty beta, we have more Jakarta EE 9 features with their name change completed.

This Open Liberty beta introduces the following Jakarta EE 9 features which now possess their all-new Jakarta EE 9 package names:

Jakarta Authentication 2.0 (jaspic-2.0)
Jakarta Authorization 2.0 (jacc-2.0)
Jakarta Persistence 3.0 (includes Eclipselink 3.0-RC1.) (jpa-3.0)

These join the Jakarta EE 9 features in previous Open Liberty betas:

Jakarta XML Binding 3.0 (jaxb-3.0)
Jakarta Managed Beans 2.0 (managedBeans-2.0)
Jakarta Concurrency 2.0 (concurrent-2.0)
Jakarta Enterprise Beans Home 4.0 (ejbHome-4.0)
Jakarta Enterprise Beans Lite 4.0 (ejbLite-4.0)
Jakarta Bean Validation 3.0 (beanValidation-3.0)
Jakarta Contexts and Dependency Injection 3.0 (cdi-3.0)
Jakarta WebSocket 2.0 (websocket-2.0; currently the integration with CDI is not completed)
JDBC 4.2 & 4.3 (jdbc-4.2 & jdbc-4.3)
Jakarta Transactions 2.0 (transaction-2.0)
Jakarta JSON Binding 2.0 (jsonb-2.0)
Jakarta JSON Processing 2.0 (jsonp-2.0)
Jakarta Servlet 5.0 (servlet-5.0)
Jakarta Server Pages 3.0 (jsp-3.0)
Jakarta Expression Language 4.0 (el-4.0)

Try it now

To try out these Jakarta EE 9 features on Open Liberty in a lightweight package, just update your build tools to pull the Open Liberty Jakarta EE 9 Beta Features package instead of the main release. The beta works with Java SE 14, Java SE 11, or Java SE 8.

If you’re using Maven, here are the coordinates:

<dependency>
    <groupId>io.openliberty.beta</groupId>
    <artifactId>openliberty-jakartaee9</artifactId>
    <version>20.0.0.10-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

dependencies {
    libertyRuntime group: 'io.openliberty.beta', name: 'openliberty-jakartaee9', version: '[20.0.0.10-beta,)'
}

Or take a look at our Downloads page.

Enable the Jakarta EE 9 beta features in your app’s server.xml. You can enable the individual features you want or you can just add the Jakarta EE 9 convenience feature to enable all of the Jakarta EE 9 beta features at once:

  <featureManager>
    <feature>jakartaee-9.0</feature>
  </featureManager>

Or you can add the Web Profile convenience feature to enable all of the Jakarta EE 9 Web Profile beta features at once:

  <featureManager>
    <feature>webProfile-9.0</feature>
  </featureManager>

Your feedback is welcomed

Let us know what you think on our mailing list. If you hit a problem, post a question on StackOverflow. If you hit a bug, please raise an issue.

See all blog posts