A preview of MicroProfile 3.3 on Open Liberty

Yasmin Aumeeruddy on Feb 14, 2020

announcements , microprofile , release ,

Post available in languages:

Open Liberty 20.0.0.2 provides bug fixes and quality improvements. If you’re curious about what’s coming in future Open Liberty releases, take a look at our previews in the latest development builds. In particular, get an early insight into support for MicroProfile 3.3 on Open Liberty.

View the list of fixed bugs in 20.0.0.2.

Run your apps using 20.0.0.2

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

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>20.0.0.2</version>
    <type>zip</type>
</dependency>

Or for Gradle:

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

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

You can now also try out early implementations of some new capabilities in the latest Open Liberty development builds.

Previews of early implementations available in development builds

MicroProfile 3.3 support
Automatically compress HTTP responses
GraphQL with Open Liberty

These early implementations are not available in 20.0.0.2 but you can try them out in our daily Docker image by running docker pull openliberty/daily. Let us know what you think!

MicroProfile 3.3 support on Open Liberty

The latest Open Liberty development builds provide previews of some MicroProfile 3.3 features, MicroProfile Metrics 2.3, MicroProfile Health 2.2, MicroProfile Config 1.4, MicroProfile Fault Tolerance 2.1.

Monitor microservice applications easily wth metrics (mpMetrics-2.3)

MicroProfile Metrics 2.3 introduces a new metric type called a Simple Timer (annotated with @SimplyTimed) and runtime provided metrics that track REST resource method usage and is backed by the new Simple Timer metric.

The new Simple Timer metric is a light-weight alternative to the existing Timer metric. It only tracks the total timing duration and counts the amount of times it was invoked. The Timer metric on the other hand is a performance heavy metric that continually calculates duration statistics and throughput statistics resulting in 14 values.

The new REST stat metrics are gathered from REST resource method usage (i.e GET, POST, PUT, DELETE, OPTIONS, PATCH, HEAD). Total time duration and total count of invocation is tracked ( by use of the Simple Timer metric). This functionality is properly enabled when used in combination with the jaxrsMonitor-1.0 feature. ALL REST stat metrics will use the REST.request metric name and will be tagged/labeled with their fully qualified class name and method signature.

To enable the feature, include the following in the server.xml:

<feature>mpMetrics-2.3</feature>

Provide your own health check procedures (mpHealth-2.2)

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

In the mpHealth-2.2 feature, all of the supported Qualifiers (Liveness and Readiness) now have annotation literals added in the specification. These ease programmatic lookup and support for inline instantiation of the qualifiers, which was not supported in the previous versions.

Also, for better integration with third party frameworks, like MicroProfile Rest Client, the HealthCheckResponse class declaration was changed from an abstract class to a concrete class with constructors allowing for direct instantiation on the consuming end.

To enable the feature, include the following in the server.xml:

<feature>mpHealth-2.2</feature>

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("myCheck");
       ...
     }
}

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

External configuration of your microservices with MicroProfile Config 1.4 (mpConfig-1.4)

The MicroProfile Config 1.4 feature provides an implementation of the Eclipse MicroProfile Config 1.4 API which has mainly had changes to the built-in and implicit converters.

The Open Liberty implementation already supported byte/Byte and short/Short but char/Character has now been added.

The implicit converter order has also been slightly changed as the order was previously of(String), valueOf(String), constructor(String), parse(CharSequence). The last two have been swapped, resulting in of(String), valueOf(String), parse(CharSequence), constructor(String). The reason for this change is that static parse(CharSequence) methods typically have some built-in caching of their results and are therefore faster in some cases. There has also been a noteable internal change to the Open Liberty implementation. In versions prior to 1.4, some dynamic caching was included which were updated by means of a background thread to scan available ConfigSources. This cache and background thread have been removed to avoid repeated queries of large ConfigSources.

To enable the feature, include the following in the server.xml:

<feature>mpConfig-1.4</feature>

For more information:

Changes to the API since 1.3

Monitor faults in your microservices (mpFaultTolerance-2.1)

MicroProfile Fault Tolerance allows developers to easily apply strategies for mitigating failure to their code. It provides annotations which developers can add to methods to use bulkhead, circuit breaker, retry, timeout and fallback strategies. In addition, it provides an annotation which causes a method to be run asynchronously.

MicroProfile Fault Tolerance 2.1 is a minor release which includes the following changes:

Adds new parameters applyOn and skipOn to @Fallback and adds skipOn to @CircuitBreaker to give the user more control over which exceptions should trigger these strategies.
Ensures that the CDI request context is active during the execution of methods annotated with @Asynchronous.
This Fault Tolerance release also adds more detail into the Javadoc and makes some minor clarifications to the specification.

For more information:

Get an introduction to MicroProfile Fault Tolerance:
- Failing fast and recovering from errors
- Preventing repeated failed calls to microservices
Reference the Javadoc
Reference the full specification including the 2.1 release notes
Report any issues on Github

Collect statistics for RESTful resource methods (jaxrsMonitor-1.0)

jaxrsMonitor-1.0 is a new feature to support MXBean and MpMetrics statistics for RESTful resource method to better understand the usage patterns and performance of services. In particular, the number of invocations and the cumulative execution time is collected. This data is useful for design, debug, and monitoring purposes. These metrics can be accessed via the jaxrsMonitor-1.0 feature in combination with the mpMetrics-2.3 feature.

Persistent EJB Timers coordination and failover across members (ejbPersistentTimer-3.2)

Prior to this feature, it was possible to partly coordinate automatic EJB persistent timers across multiple Open Liberty servers by configuring the EJB timer service to persist timers to the same database. This caused a single timer instance to be created on one of the servers but without the ability to fail over to another server if the original server stops or crashes. To enable fail over, this feature adds a new configurable attribute, missedTaskThreshold, which specifies the maximum amount of time that you want to allow for an execution of a persistent timer to complete before allowing another server to take over and run it instead.

Enable the EJB persistent timers feature, or another feature that implicitly enables it, such as ejb-3.2 and configure it to use a data source. In this example, we let it use the Java/Jakarta EE default data source. This much is required regardless of whether fail over is desired. To use fail over, ensure that configuration for all servers is pointing at the same database and uses the same database schema. Then include a value for the missedTaskThreshold attribute.

<server>
  <featureManager>
    <feature>ejbPersistentTimer-3.2</feature>
    <feature>jdbc-4.2</feature>
    ... other features
  </featureManager>

  <dataSource id="DefaultDataSource">
    <jdbcDriver libraryRef="OraLib"/>
    <properties.oracle URL="jdbc:oracle:thin:@//localhost:1521/EXAMPLEDB"/>
    <containerAuthData user="dbuser" password="dbpwd"/>
  </dataSource>
  <library id="OraLib">
    <file name="${shared.resource.dir}/jdbc/ojdbc8.jar" />
  </library>

  <!-- The following enables fail over for persistent timers -->
  <persistentExecutor id="defaultEJBPersistentTimerExecutor" missedTaskThreshold="5m"/>

  ...
</server>

Automatically compress HTTP responses

You can now try out HTTP response compression.

Previous to this feature, Liberty only considered compression through the use of the $WSZIP private header. There was no way for a customer to configure the compression of response messages. Support now mainly consists of using the Accept-Encoding header in conjunction with the Content-Type header, of determining if compression of the response message is possible and supported. It allows the Liberty server to compress response messages when possible. It is beneficial because customers will want to use the compression feature to help reduce network traffic, therefore reducing bandwidth and decreasing the exchange times between clients and Liberty servers.

A new element, <compression>, has been made available within the <httpEndpoint> for a user to be able to opt-in to using the compression support.

The optional types attribute will allow the user to configure a comma-delimited list of content types that should or should not be considered for compression. This list supports the use of the plus “+” and minus “-“ characters, to add or remove content types to and from the default list. Content types contain a type and a subtype separated by a slash “/“ character. A wild card "*" character can be used as the subtype to indicate all subtypes for a specific type.

The default value of the types optional attribute is: text/*, application/javascript.

Configuring the optional serverPreferredAlgorithm attribute, the configured value is verified against the “Accept-Encoding” header values. If the client accepts the configured value, this is set as the compression algorithm to use. If the client does not accept the configured value, or if the configured value is set to ‘none’, the client preferred compression algorithm is chosen by default.

<httpEndpoint  id="defaultHttpEndpoint"
        httpPort="9080"
        httpsPort="9443">
    <compression types=“+application/pdf, -text/html” serverPreferredAlgorithm=“gzip”/></httpEndpoint>

Open Liberty supports the following compression algorithms: gzip, x-gzip, deflate, zlib, and identity (no compression)

The Http Response Compression functionality has been designed from the following Open Liberty Epic: #7502. The design is outlined within the Epic for more detailed reading. The basic flow of the design is shown in the below diagrams:

You are now free to use GraphQL with Open Liberty!

In our latest OpenLiberty development builds, users can now develop and deploy GraphQL applications. GraphQL is a complement/alternative to REST that allows clients to fetch or modify remote data, but with fewer round-trips. Liberty now supports the (still under development) MicroProfile GraphQL APIs (learn more) that allow developers to create GraphQL apps using simple annotations - similar to how JAX-RS uses annotations to create a RESTful app.

Developing and deploying a GraphQL app is cinch - take a look at this sample to get started with these powerful APIs!

View the list of fixed bugs from 20.0.0.2

Get Liberty 20.0.0.2 now

Available through Maven, Gradle, Docker, and as a downloadable archive.

See all blog posts