back to all blogsSee all blog posts

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

image of author
Jakub Pomykala on Nov 24, 2020
Post available in languages:

Open Liberty 21.0.0.1-beta provides MicroProfile Rest Client 2.0 (which is part of MicoProfile 4.0), which adds support for HTTP proxy servers as well as automatically following HTTP redirects. Also, you can now use Kubernetes secrets in Liberty variables, plus Jakarta Faces Container 3.0 and Jakarta Enterprise Beans Persistent Timer 4.0 which are part of Jakarta EE 9.

We have two beta packages for Open Liberty:

  • All Beta Features: a 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.

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 Rest Client 2.0

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:

    <featureManager>
        <feature>mpRestClient-2.0</feature>
    </featureManager>

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

    <featureManager>
        <feature>microprofile-4.0</feature>
    </featureManager>

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:

<dependency>
    <groupId>org.eclipse.microprofile.rest.client</groupId>
    <artifactId>microprofile-rest-client-api</artifactId>
    <version>2.0</version>
    <scope>provided</scope>
</dependency>

or, if you use Gradle:

dependencies {
    mpRestClient group: 'org.eclipse.microprofile.rest.client', name: 'microprofile-rest-client-api', version: '2.0'
}

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:

MyClient client =
    RestClientBuilder.newBuilder()
                     .baseUri(someURI)
                     .queryParamStyle(QueryParamStyle.COMMA_SEPARATED) // or ARRAY_PAIRS or MULTI_PAIRS (default)...
                     .proxyAddress("myProxyServer", 1080)
                     .followRedirects(true)
                     .build(MyMultiValuedQueryParamClient.class);

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

  • com.mypkg.MyClient/mp-rest/queryParamStyle=COMMA_SEPARATED

  • com.mypkg.MyClient/mp-rest/proxyAddress=myProxyServer:1080

  • com.mypkg.MyClient/mp-rest/followRedirects=true

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:

Using Kubernetes secrets in Liberty variables

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:

blog 21001 beta username password

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

blog 21001 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:

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 15, 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>21.0.0.1-beta</version>
  <type>pom</type>
</dependency>

Or for Gradle:

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

Or take a look at our Downloads page.

Jakarta EE 9 Beta Features package

The main change visible to developers in Jakarta EE is the names of packages changing to accomodate the new jakarta.* namespace. In this Open Liberty beta, we have two new API Release Candidates to join the expanding library of supported Jakarta packages.

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

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

  • Jakarta Password Utilities 1.0 (passwordUtilities-1.0)

  • Jakarta Connectors 2.0 Inbound Security (connectorsInboundSecurity-2.0)

  • Jakarta WebSocket 2.0 (websocket-2.0; now with full CDI integration)

  • RESTful Web Services 3.0 (restfulWS-3.0 and restfulWSClient-3.0)

  • Jakarta Server Faces 3.0 (faces-3.0)

  • Jakarta Connectors 2.0 (connectors-2.0)

  • Jakarta Enterprise Beans 4.0 (enterpriseBeans-4.0)

  • Jakarta Enterprise Beans Remote 4.0 (enterpriseBeansRemote-4.0)

  • Jakarta Enterprise Beans Home 4.0 (enterpriseBeansHome-4.0)

  • Jakarta Enterprise Beans Lite 4.0 (enterpriseBeansLite-4.0)

  • Jakarta EE Application Client 9.0 (javaeeClient-9.0)

  • 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)

  • Jakarta XML Binding 3.0 (jaxb-3.0)

  • Jakarta Managed Beans 2.0 (managedBeans-2.0)

  • Jakarta Concurrency 2.0 (concurrent-2.0)

  • Jakarta Bean Validation 3.0 (beanValidation-3.0)

  • Jakarta Contexts and Dependency Injection 3.0 (cdi-3.0)

  • Message-Driven Beans 4.0 (mdb-4.0)

  • 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 now pages-3.0)

  • Jakarta Expression Language 4.0 (el-4.0 now expressionLanguage-4.0)

Jakarta Faces Container 3.0

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:

    <featureManager>
        <feature>facesContainer-3.0</feature>
    </featureManager>

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

Jakarta Enterprise Beans Persistent Timer 4.0

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 3.0

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:

 <featureManager>
       <feature>messagingClient-3.0</feature>
       <feature>mdb-4.0</feature>
       <feature>jndi-1.0</feature>
 </featureManager>

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:

  <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>

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 15, 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>21.0.0.1-beta</version>
    <type>zip</type>
</dependency>

Or for Gradle:

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

Or take a look at our Downloads page.

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.