MicroProfile 3.2 is now available on Open Liberty 19.0.0.12

Yasmin Aumeeruddy on Dec 6, 2019

announcements , microprofile , release , security , metrics ,

Post available in languages:

Open Liberty 19.0.0.12 provides support for MicroProfile 3.2, allowing users to provide their own health check procedures and monitor microservice applications easily with metrics. In addition, updates allow trust to be established using the JDK’s default truststore or a certificate through an environment variable.

In Open Liberty 19.0.0.12:

MicroProfile 3.2 support
- Provide your own health check procedures (MicroProfile Health Check 2.1)
- Monitor microservice applications easily with metrics (MicroProfile Metrics 2.2)
Jaeger support in MicroProfile Open Tracing
Trusted certificate enhancements (Transport Security 1.0)
Liberty reader role support

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 the use of GraphQL with Open Liberty.

Run your apps using 19.0.0.12

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

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

Or for Gradle:

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

Or if you’re using Docker:

FROM open-liberty

Or take a look at our Downloads page.

MicroProfile 3.2 support

Add the whole of MicroProfile 3.2 to your application with this convenience feature in your server.xml:

<featureManager>
  <feature>microProfile-3.2</feature>
<featureManager>

The microProfile-3.2 feature automatically includes the following features in your app: JAX-RS 2.1, CDI 2.0, JSON-P 1.1, JSON-B 1.0, MicroProfile Config 1.3, MicroProfile Fault Tolerance 2.0, MicroProfile Health Check 2.1, MicroProfile JWT 1.1, MicroProfile Metrics 2.2, MicroProfile OpenAPI 1.1, MicroProfile OpenTracing 1.3, and MicroProfile Rest Client 1.3.

The MicroProfile Health Check and Metrics features contain updates.

Provide your own health check procedures (MicroProfile Health Check 2.1)

MicroProfile Health Check 2.1 enables you to provide your own health check procedures to be invoked by Liberty, to verify the health of your microservice:

HealthCheckResponse.up("myCheck");

In previous versions, to define a simple successful/failed named health check response, the application level code is always expected to use several static methods together from the HealthCheckResponse API to retrieve a HealthCheckResponseBuilder used to construct a HealthCheck response.

In the mpHealth-2.1 feature for OpenLiberty, you can now use convenient and simpler methods from standard Java APIs, to construct UP/DOWN named health check responses, in your applications, such as;

HealthCheckResponse.named(“myCheck”).up().build();

To make it work include the following line in the server.xml file:

<feature>mpHealth-2.1</feature>

Applications are expected to provide health check procedures by implementing the HealthCheck interface with the @Liveness or @Readiness annotations, which are used by 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 constructing using the simple up() and down() methods from the API. To view the status of each health check, access either the http://<hostname>:<port>/health/live or http://<hostname>:<port>/health/ready endpoints.

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

For more information:

Monitor microservice applications easily wth metrics (MicroProfile Metrics 2.2 )

MicroProfile Metrics 2.2 enables developers to instrument metrics in their (microservice) applications for easy monitoring by their operations team.

Previously, the MetadataBuilder API had reusable() and notReusable() method to set the reusable field to true or false. The MetadataBuilder API has been changed to include a new setter method for the reusable attribute. This change is implemented so the MetadataBuilder API follows the builder pattern.

To enable the feature in the server.xml file:

<feature>mpMetrics-2.2</feature>

The example shows how to set the reusable field with the MetadataBuilder API:

MetadataBuilder mdb = Metadata.builder();

mdb = mdb.withName("metricName").withType(MetricType.COUNTER)
  .reusable(resolveIsReusable());

For more information:

Jaeger support added for tracing (MicroProfile OpenTracing 1.3)

Open Liberty has added support for Jaeger in MicroProfile OpenTracing. A sample tracer is available here for using Zipkin as a tracing backend. With the addition of Jaeger support, developers can also use Jaeger as a tracing backend.

You can download the Jaeger client version 0.34.0 library and its dependencies from Maven repository.

In the server.xml:

Add <feature>mpOpenTracing-1.3</feature> under <featureManager> section.

    <library id="jaegerLib" apiTypeVisibility="+third-party" >
        <file name="<path>/jaegerLib_0.34/gson-2.8.2.jar" />
        <file name="<path>/jaegerLib_0.34/jaeger-client-0.34.0.jar" />
        <file name="<path>/jaegerLib_0.34/jaeger-core-0.34.0.jar" />
        <file name="<path>/jaegerLib_0.34/jaeger-thrift-0.34.0.jar" />
        <file name="<path>/jaegerLib_0.34/jaeger-tracerresolver-0.34.0.jar" />
        <file name="<path>/jaegerLib_0.34/libthrift-0.12.0.jar" />
        <file name="<path>/jaegerLib_0.34/slf4j-api-1.7.25.jar" />
        <file name="<path>/jaegerLib_0.34/slf4j-jdk14-1.7.25.jar" />
        <file name="<path>/jaegerLib_0.34/opentracing-util-0.31.0.jar" />
        <file name="<path>/jaegerLib_0.34/opentracing-noop-0.31.0.jar" />
    </library>

Define your appplication:

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

You can find out more about about Jaeger settings set up 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 spans created by the applications.

Trusted certificate enhancements (Transport Security 1.0)

Open Liberty now offers new options to help establish trust for TLS connections. An easy way to use the JDK’s default truststore for trust and a way to pass the certificate needed to establish trust to a truststore through an environment variable is now provided.

Establishing trust using the JDK’s default truststore

By default, the JDK default truststore is the cacerts file. The default truststore may be set by the javax.net.ssl.truststore system property or the jssecacerts file if users have one configured. For Open Liberty to use what is configured as the JDK default truststore the trustDefaultCerts attribute needs to be set to true on the ssl element. It is set to false by default. For example:

<ssl id="defaultSSLConfig" keyStoreRef="defaultKeyStore" trustStoreRef="defaultTrustStore" trustDefaultCerts="true" />
<keyStore id="defaultKeyStore" location="key.p12" type="PKCS12" password="your_password"  />
<keyStore id="defaultTrustStore" location="trust.p12" type="PKCS12" password="your_password" />

With trustDefaultCerts set to true, the server will try to establish trust with the configured truststore, in this case defaultTrustStore, first. If trust is not establish with the configured truststore then it will try to use the JDK’s default truststore to establish trust.

Providing a certificate through an environment variable to establish trust

Open Liberty will read a certificate from an environment variable and add it to a keystore or truststore so it can be used for trust. The certificate will be added to the runtime copy of the keystore or truststore and will not be stored to the file system. If the keystore configuration includes the readOnly attribute set to true then the certificate will not be included.

The environment variable key must be in the format cert_ + keystore id. For example:

<keyStore id="myKeyStore" location="myKey.p12" type="PKCS12" password="your_password" />

The key of the environment variable should be cert_myKeyStore (it is case sensitive).

The value of the environment variable can either be a certificate in the base 64-bit format or the path to a file containing a base 64-bit encode certificate or DER encoded certificate. If using the base 64-bit encode certificate directly on the environment variable, it must contain the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- tags. For example:

cert_myKeyStore="-----BEGIN CERTIFICATE-----
....
-----END CERTIFICATE-----"

The environment variable for a file will look similar to:

cert_myKeyStore=/Users/me/servercert.crt

Any value not starting with the -----BEGIN CERTIFICATE-----` tag will be treated like a file.

Liberty reader role support (Application Security 2.0 and Application Security 3.0)

The reader role is a management role that allows read-only access to select administrative REST APIs as well as the Admin Center UI (adminCenter-1.0).

Prior to this release, the Administrator management role was the only management role within Open Liberty and it provided read and write access. The new Reader management role provides the ability to assign a read-only role to users and groups. This will allow those users and groups to monitor the server without granting those users the ability to modify the server in anyway.

Using the new Reader management role is nearly identical to using the Administrator management role. In the server.xml include the appSecurity-2.0 or appSecurity-3.0 feature and also add the new reader-role configuration element, that specifies the group(s), user(s), and/or the access ID of the group(s) or user(s) that should be granted the Reader management role.

<server>
    <featureManager>
        <feature>appSecurity-3.0</feature>
    </featureManager>

    <reader-role>
        <group>group</group>
        <group-access-id>group:realmName/groupUniqueId</group-access-id>
        <user>user</user>
        <user-access-id>user:realmName/userUniqueId</user-access-id>
    </reader-role>
</server>

Previews of early implementations available in development builds

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

You are now free to use GraphQL with Open Liberty

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

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 19.0.0.12

Get Liberty 19.0.0.12 now

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

See all blog posts