Well, this is exciting! Our first proper release of Open Liberty and the Open Liberty Tools! In Open Liberty 18.104.22.168 is a full implementation of MicroProfile 1.2, some Liberty Gradle plugin updates, and some transport security updates. You might have noticed that the download actually went live some time ago but we were so caught up with JavaOne and other conferences (then recovering from all the excitement) that this post got…ahem…slightly overlooked. Anyway, it’s here now…read on!
You can now download Open Liberty and Open Liberty Tools 22.214.171.124.
Alternatively, if you’re using Maven, here are the coordinates:
<dependency> <groupId>io.openliberty</groupId> <artifactId>openliberty-runtime</artifactId> <version>126.96.36.199</version> <type>zip</type> </dependency>
Or if you’re using Docker:
docker pull openliberty/open-liberty
In Open Liberty 188.8.131.52, you’ll find our completed implementation of MicroProfile 1.2, as well as new and improved build tools:
Open Liberty already implemented Eclipse MicroProfile 1.0 with JAX-RS 2.0, CDI 1.2, and JSON-P 1.0. That was easy. I mean, pity the Java EE application server that can’t do that. Now we’ve completed the MicroProfile 1.2 set with all these other MicroProfile features…
To enable all the MicroProfile 1.2 features, add this definition to your
<featureManager> <feature>microProfile-1.2</feature> </featureManager>
Alternatively, you can add the individual features as described below.
MicroProfile Fault Tolerance
The increasing size of applications, newer architectures that are as likely to 'scale out' as to 'scale up', and the rising popularity of microservice architectures, it is increasingly important to build fault tolerance into our system architecture.
Fault tolerance can be improved using a number of well-tested approaches that handle failure:
TimeOut: Limit the amount of time we are prepared to wait for a result
RetryPolicy: Control how much we are prepared to re-submit a request
Fallback: Specify what should we do when the primary service cannot be used successfully
Bulkhead: If calls to a service are slow (perhaps it is overloaded or we are timing out), specify what proportion of our local resources we are prepared to get involved in the traffic jam
CircuitBreaker: When a service is proving unreliable, for example timing out, we can choose to 'fail fast' by automatically failing calls to it under control
With the Microprofile Fault Tolerance specification, we can control all these aspects with easy-to-use Java annotations at a method or class level that is independent of any particular vendor or implementation library.
To add just the Fault Tolerance feature, update your
<featureManager> <feature>mpFaultTolerance-1.0</feature> </featureManager>
Find out more about the Fault Tolerance feature in GitHub.
MicroProfile Config API 1.1
The MicroProfile Configuration specification provides a single way to view and access multiple sources of configuration, such as properties files and environment variables, including bootstrap.properties, user-level properties files, registered Java classes that implement the ConfigSource API, and the Java System properties.
When your applications are deployed as microservices, having a single place to update the configuration data of multiple microservices is useful for several reasons. Building systems as collections of independent microservices increases the number of services that need to be managed. Different stages in the pipeline often use different configuration sources for a single piece of configuration data and a given component needs updating as it moves through the pipeline. Containerisation of services means that even while a component is ‘live’ in production, the environment it is running in might be more dynamic and the components need configuration updates without being restarted.
The Config API allows for a consistent means to access configuration data from pluggable configuration sources. Configuration properties can be injected using Java CDI in a form that is easy to consume. Data values and sources can vary across the devOps pipeline without code change or repackaging, and dynamic and fully typed data is catered for.
To add just the Config API feature, update your
<featureManager> <feature>mpConfig-1.1</feature> </featureManager>
Find out more about the Config API feature in GitHub.
MicroProfile Metrics provides a way for developers to instrument their microservices and applications that will be portable across all MicroProfile Metrics implementations. The API is similar to the Dropwizard Metrics API that many developers are already familiar with. Using MicroProfile Metrics avoids the need to find and include third-party metrics libraries and integrate those libraries with Liberty.
For operations teams, MicroProfile Metrics provides a consistent way to access metrics from their Liberty servers through a simple REST interface. The REST API can return output compatible with Prometheus or with any monitoring tools that can consume JSON.
Developers: To add just the Metrics feature, update your
<featureManager> <feature>mpMetrics-1.0</feature> </featureManager>
Ops: To enable the
/metrics REST interface, add the following definition to your
<featureManager> <feature>mpMetrics-1.0</feature> </featureManager> <quickStartSecurity userName="theUser" userPassword="thePassword"/> <keyStore id="defaultKeyStore" password="Liberty"/>
Then verify that things are set up correctly by hitting
Find out more about the Metrics feature in GitHub.
MicroProfile Health defines an API for providing health check procedures in a microservice and a runtime environment for invoking installed health checks and aggregating an overall response.
MicroProfile Health specifies a standard health check API that works across any runtime supporting MicroProfile 1.2. The feature provides a default response even when the installed microservice does not implement any health checks. It provides a standard health check URL, allowing for a consistent way to configure service monitors (e.g., Kubernetes liveness checks).
mpHealth-1.0 feature to the server configuration and add zero or more health checks to the microservice. A
/health context is provided by the server for invoking the health checks.
To add just the Health feature, update your
<featureManager> <feature>mpHealth-1.0</feature> </featureManager>
Find out more about the Health feature in GitHub.
MicroProfile JSON Web Token
With the MicroProfile JSON Web Token feature, an administrator can configure Liberty to perform authentication and authorization based on incoming JWT without requiring a user registry.
An application developer can write a JAX-RS application to programmatically authorize resource access using CDI injection or the standard JAX-RS container API in an interoperable way.
To add just the MicroProfile JSON Web Token feature, update your
<featureManager> <feature>mpJwt-1.0</feature> </featureManager>
Find out more about the MicroProfile JSON Web Token feature in GitHub.
Build tools updates
Liberty Gradle plugin
The Liberty Gradle plugin has many improvements to help you install and manage your Liberty server. These tasks can be used to test your web application on a Liberty server more easily and for packaging your servers. The plugin update includes enhancements to the following tasks:
Add support to install using Maven repository coordinates
Provide Liberty license upgrade
Support installing from a local folder
Add timeout test support
Add application start verification
Improved application installation
Support multiple WAR file tasks for installation
Loose application support to make debugging faster
Server configuration creation
jvm.optionsfrom inline configuration
Copy a folder of configuration
In addition there are:
Enhancements to the Liberty Gradle lifecycle with task dependencies
The Liberty Gradle plugin is used with the Gradle WAR plugin to install project WAR files and loose applications to a Liberty Server. For more details, see the Liberty Gradle plugin documentation in GitHub.
The Transport Security feature provides dynamic SSL filters. This enables administrators to configure SSL configuration to be used for outbound connections based on the host (or host and port) of the destination. You can configure the SSL configuration without having to use direct references in individual components.
To enable an outbound SSL filter in the
server.xml, add an element called
<outboundConnection />. The
<outboundConnection /> element is nested in the
<ssl /> element. The
<outboundConnection /> element contains two attributes:
host attribute is required; the
port attribute is optional. A missing
port attribute means any port on the configured host. When configured, and an outbound SSL connection is made, the connection can be matched to an SSL configuration that is assigned to the destination host, or host and port, that is specified in the
<outboundConnection /> element.
In the following example, the outbound SSL connection going to a machine called
testMachine and port
9443 uses an SSL context created with information from the
<ssl /> element called
<ssl id="customSSLSettings" keyStoreRef="customKeyStore" trustStoreRef="customTrustStore" sslProtocol="TLSv1.2" clientAuthenticationSupported="true" > <outboundConnection host="testHostMachine" port="9443"/> </ssl>