MicroProfile Rest Client 2.0, using Kubernetes secrets in Liberty variables and more Jakarta EE 9 features in Open Liberty 21.0.0.1-beta

MicroProfile REST Client is a type-safe client API enabling rapid development of applications capable of consuming RESTful services. Version 2.0 is the latest update and adds support for HTTP proxy servers, automatically following HTTP redirects, Server Sent Events, and additional configuration options for JSON-B providers and multiple query parameters.

To enable this feature, add <feature>mpRestClient-2.0</feature> to the list of features in the <featureManager> element as shown in the example below:

Alternatively, the microprofile-4.0 convenience feature can be used instead, as shown below:

In order to start coding with the updated API, you will also need to pull in the MP Rest Client 2.0 dependencies. If you use Maven, try these coordinates:

or, if you use Gradle:

This allows you to change how multi-valued query parameters are formatted, specify a proxy server, configure the client to automatically follow redirects and more. Here is an example:

These can also be configured via MP Config using the following properties, respectively:

In a future blog post, we’ll discuss how you can also use MP Rest Client 2.0 to consume Server Sent Events.

For examples of how to use these new features, please refer to the specification document or the MicroProfile Rest Client project page.

You can also see these new features in action below:

In a cloud environment, sensitive information such as passwords and OAuth tokens may be stored in Kubernetes secrets. To access these secrets today in Liberty via configuration variables they would need to be exposed as environment variables in a Kubernetes pod. This update will allow configuration variables to be automatically populated from Kubernetes secrets without having to expose them as environment variables.

To make use of this function, the Kubernetes secrets need to be mapped to the file system, either by using the service binding operator or by mounting the secrets to a volume in the pod definition. Files will be read from the location defined in the SERVICE_BINDING_ROOT environment variable, which defaults to WLP_CONFIG_DIR/bindings. The variable name will be taken from the name of the file, and the value will be the contents of the file.

For example, we may have a Kubernetes secret named 'account-database' that contains a username and password:

The service binding operator can automatically map that secret to the file system, or it could be done manually in a deployment definition:

The above definition will result in the files /bindings/account-database/username and /bindings/account-database/password being created when the pod is created. Liberty will create variables from both files, and users can access them using normal Liberty variable syntax, ${account-database/username} and ${account-database/password}.

For more information:

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 15, Java SE 11, or Java SE 8.

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

Or for Gradle:

Or take a look at our Downloads page.

This feature is part of the Jakarta EE9 features. The largest change in this feature is it has been updated to support and reference the new jakarta namespace. Previously the jsfContainer features supported the javax namespace, but as part of Jakarta EE9, the packages were updated from javax to jakarta.

The Open Liberty facesContainer-3.0 allows developers to use their preferred Jakarta Server Faces API & Implementation, such a Mojarra, by bundling it with their application. Historically, this container feature has been named using the acronym jsf (such as jsfContainer-2.3). However, starting with Jakarta Faces Container 3.0, the feature name will now begin with faces to move away from the Oracle trademarked acronyms. Otherwise, developers can simply use the Open Liberty provided faces-3.0 feature which uses the Apache MyFaces API and Implementation.

The following feature can be included in your server.xml:

Additional information about the Jakarta Server Faces 3.0 specification can be found here.

The enterpriseBeansPersistentTimer-4.0 feature enables the use of persistent timers in Jakarta Enterprise Beans. Configuration is the same as the corresponding feature from Jakarta EE 8, ejbPersistentTimer-3.2. With this final Jakarta Enterprise Beans 4.0 feature, the full capabilities of Jakarta Enterprise Beans 4.0 are now available in beta.

Jakarta Messaging is an API and services that enable applications to create, send, and receive messages via loosely coupled, reliable asynchronous communications. Support for version 3.0 updates the API and services to the jakarta.* namespace and introduces four new features for Jakarta EE 9: messaging-3.0, messagingClient-3.0, messagingServer-3.0, messagingSecurity-3.0.

Configuration is the same as the corresponding features for Jakarta EE 8 (jms-2.0, wasJmsClient-2.0, wasJmsServer-1.0, wasJmsSecurity-1.0) with one exception: version 3.0 support does not introduce a new feature corresponding to jmsMdb-1.0. Instead, use Jakarta EE 9 feature mdb-4.0 when deploying message-driven beans to connect to MQ providers, Jakarta Connectors resource adapters, or the embedded messaging server.

To enable the new Jakarta EE 9 messaging features, add them to your server.xml. Here’s a feature configuration that enables applications to access message queues via the Messaging 3.0 API, enables message-driven beans to connect to the embedded messaging server, and enables JNDI lookups for messaging resources.

The following features can be included in your server.xml:

Additional information about the Jakarta Messaging 3.0 specification can be found here.

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:

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

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 15, Java SE 11, or Java SE 8.

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

Or for Gradle:

Or take a look at our Downloads page.