WebSphere Liberty 220.127.116.11 is now available to download. It contains a full implementation of MicroProfile 1.2, improvements to the Liberty Maven and Gradle build tools, and more as well!
Since our last release of WebSphere Liberty, as you may have heard, we’ve released the main parts of Liberty as the open source project Open Liberty. WebSphere Liberty is built on Open Liberty, which means that a lot of the Liberty development is now done in the open on GitHub. You can find out more about Open Liberty on the Open Liberty website.
We’d love you to get involved in any way that you can, such as testing the code in ways that you use Liberty and raising issues on GitHub, or create pull requests on the code and documentation. You can contribute to discussions about Open Liberty on the mailing list.
What’s new in WebSphere Liberty 18.104.22.168?
- Request for enhancements (RFEs) (Added 2018-01-18)
- MicroProfile 1.2 new features
- Build tools updates
- Other runtime feature updates
Request for enhancements (RFEs)
In this release, the following RFE was completed:
MicroProfile 1.2 new features
With this release, we complete the WebSphere Liberty implementation of MicroProfile 1.2. Joining the previously released JAX-RS2.0, CDI 1.2, and JSON-P 1.0 features, we now add MicroProfile Fault Tolerance, Config API 1.1, Metrics, Health, and JSON Web Token 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>
Then take a look at these code snippets in the Knowledge Center to get started.
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.
microProfile-1.2 feature can be used to enable all MicroProfile features. If you want only the
mpMetrics-1.0 feature, hereâ€™s what you want in your
<featureManager> <feature>mpMetrics-1.0</feature> </featureManager>
To find out more, see the Knowledge Center: Adding metrics to applications
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
To find out more, see the Knowledge Center: Monitoring the Liberty server runtime environment
Find out more about the Metrics feature in GitHub.
MicroProfile Health feature
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>
For more details, see the documentation in the Knowledge Center.
Find out more about the Health feature in GitHub.
MicroProfile JSON Web Token
With the MicroProfile JSON Web Token feature, 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.
An administrator can configure Liberty to perform authentication and authorization based on incoming JWT without requiring a user registry.
To add just the MicroProfile JSON Web Token feature, update your
<featureManager> <feature>mpJwt-1.0</feature> </featureManager>
For more details, see the documentation in the Knowledge Center
Find out more about the MicroProfile JSON Web Token feature in GitHub.
Liberty 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:
- Documentation improvements
- Enhancements to the Liberty Gradle lifecycle with task dependencies
The open source 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.
Liberty Maven enhancements in WebSphere Developer Tools
The WebSphere Developer Tools (WDT) and the Liberty Maven plugin added integrated support for enterprise applications built using the Liberty Maven plugin. The plugin can now build your whole enterprise application as a loose application for easier debugging in the WDT environment. No more rebuilding your Maven EAR project for every application update. The integration between WDT and Maven projects allow the servers created by the Liberty Maven plugin to be managed by WDT. This support is an extension to the Maven web application support previously added.
When importing EAR projects using the Liberty Maven plugin, WDT recognizes the project as containing Liberty servers it can manage.
Find out more about the open source Liberty Maven plugin in the Liberty Maven plugin on GitHub.
Other runtime updates
OpenAPI v3 is the official specification for modelling RESTful APIs. The new openapi-3.0 feature exposes annotations and programming interfaces to facilitate the auto-generation of OpenAPI v3 documents from Java applications. These APIs are a result of the collaboration between SmartBear and IBM in the Swagger open source repositories (https://github.com/swagger-api/swagger-core) , and thus are exposed as 3rd party APIs in Liberty.
To enable the OpenAPI feature, update your
<featureManager> <feature>openapi-3.0</feature> </featureManager>
For more details, see the Knowledge Center
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
<featureManager> <feature>transportSecurity-1.0</feature> </featureManager> <ssl id="customSSLSettings" keyStoreRef="customKeyStore" trustStoreRef="customTrustStore" sslProtocol="TLSv1.2" clientAuthenticationSupported="true" > <outboundConnection host="testHostMachine" port="9443"/> </ssl>
For more details, see the Knowledge Center documentation
Request timing thresholds can now be set at a per-application or per-servlet level. This means that the one or two oddball servlets you have that don’t fit the model of the rest of the application can now have their thresholds set separately. This means you can monitor the rest of your application more closely for timing-related problems.
To configure fine-grained request timing, use the
<jdbcTiming/> child elements of the
<requestTiming/> configuration in
<featureManager> <feature>requestTiming-1.0</feature> </featureManager> <!-- Defaults for all timed requests --> <requestTiming slowRequestThreshold="5s" hungRequestThreshold="10s"> <!-- Specific thresholds for this application --> <servletTiming appName="jdbcTestPrj_4" slowRequestThreshold="90s" hungRequestThreshold="120s"/> <!-- Specific thresholds for this specific servlet (in any app) --> <servletTiming servletName="MyServlet" slowRequestThreshold="30s" hungRequestThreshold="60s"/> <!-- Specific timings for this specific servlet in this specific app --> <servletTiming appName="jdbcTestPrj_3" servletName="MyOtherServlet" slowRequestThreshold="120s" hungRequestThreshold="180s"/> <!-- Specific threshold for all JDBC requests --> <jdbcTiming slowRequestThreshold="2m" hungRequestThreshold="5m"/> </requestTiming>
More details can be found in the Knowledge Center documentation
This release updates the
mongodb-2.0 feature. It adds SSL communication between Liberty and MongoDB and supports both SSL encryption and certificate authentication over SSL.