Java EE 8 updates include reactive client and server-side events in JAX-RS 2.1, asynchronous events in CDI 2.0, Servlet 4.0 including HTTP/2 support, JSF 2.3 and JPA 2.2.
As well as the Java EE 8 updates, you can now deploy your Spring Boot applications to Liberty, control certificate mapping to users, document your RESTful APIs with OpenAPI, more simply manage collective security, and configure single logout for single sign-on (SSO) applications.
Join our free webcast
Learn about Liberty V184.108.40.206, try it out, and ask questions of the team (choose the date that suits your timezone):
Download WebSphere Liberty 220.127.116.11 now
What’s new in WebSphere Liberty 18.104.22.168?
- Full implementation of Java EE 8!
- Quickly enable Java EE 8 (Full or Web profile) with convenience features
- Enable single logout of SAML sessions in your web app
- Document RESTful APIs in your Java apps with OpenAPI
- Manage high availability servers with Liberty collectives
- Request for enhancements (RFEs) completed in WebSphere Liberty 22.214.171.124
Full support for Java EE 8 with convenience features
WebSphere Liberty is the first Java EE 8 compatible application server! In fact, we’re so first that they’ve not had a chance to update the official page yet…
WebSphere Liberty is built on the Open Liberty open source project, which contains the full Java EE 8 implementation (along with MicroProfile 1.3). To find out more about the Java EE 8 features, see the Open Liberty 126.96.36.199 blog post.
Quickly enable Java EE 8 (Full or Web profile) with convenience features
You can enable all of the Java EE 8 features (or the more lightweight set of Web Profile features) with a single feature in your
server.xml. Just add the relevant feature definition to your
For Java EE 8 Web Profile:
<featureManager> <feature>webProfile-8.0</feature> </featureManager>
Or for Java EE 8 Full Platform:
<featureManager> <feature>javaee-8.0</feature> </featureManager>
Enable single logout of SAML sessions in your web app
Liberty as a SAML service provider is now equipped with the SAML single logout function which allows users to terminate all the login sessions established using SAML Web single sign-on (SSO). This single logout function can be initiated from either the service provider or the identity provider. Single logout improves security by avoiding abandoned login sessions, and can simplify administration by providing a centralized way to log out.
Using SAML Web SSO, the user logs in to the identity provider once and receives unlimited access to different web applications without additional login prompts. It is not easy for the end user to be aware of all the opened web sessions and, as a result, they can end up with orphaned log-in sessions which might pose a security risk.
This SAML single logout (SLO) function enables near-simultaneous logout of an end user. It also allows the users to terminate all their login sessions with one click of a mouse button and can be initiated from service provider or identity provider.
To enable the SSO feature in the
<featureManager> <feature>samlWeb-2.0</feature> </featureManager>
To configure the Liberty service provider (SP) for SAML single logout:
For identity provider initiated logout, no additional configuration is required. An SLO endpoint URL is published in the clientâ€™s metadata, and SLO-capable identity providers can read the metadata and call it.
To configure the Liberty service provider (SP) for SAML single logout, add a
samlWebSso20 element to
<server> <samlWebSso20 id="sp2" ... spLogout="true" /> ... </server>
Subsequent calls to
ibm_security_logout are then upgraded to perform SAML single logout.
The SingleLogoutService URL is
https://. That URL will also be included in in the Liberty SP’s metadata, available at
For more info:
Document RESTful APIs in your Java apps with OpenAPI
The new OpenAPI 3.1 (
openapi-3.1) feature is an extension of the MicroProfile OpenAPI 1.0 (
mpOpenAPI-1.0) feature. In addition to providing support for the MicroProfile OpenAPI 1.0 specification, this feature also provides an aggregated view of APIs from multiple applications deployed in the server.
To enable the OpenAPI 3.1 feature, add the feature definition to your
<featureManager> <feature>openapi-3.1</feature> </featureManager>
Then use one of the documentation methods specified in this section of the specification for each of your applications. You can view the generated aggregated OpenAPI document in the endpoint
/api/docs, or view the rendered user interface in the endpoint
Customize the URL path of the public endpoints by using MicroProfile Configuration. For example, setting the
mp.openapi.extensions.liberty.public.url property to
/my/custom changes the location of the aggregated document endpoint from
/my/custom/docs. Similarly, the location of the rendered user interface changes from
You can designate APIs as private by setting the
mp.openapi.extensions.liberty.public property to
false at the application level. This setting hides APIs from the public endpoint view. Setting the
mp.openapi.extensions.liberty.enable.private.url property to
true makes private APIs available at the following private endpoints:
/ibm/api/docs (aggregated document) and
For more info:
Manage high availability servers with Liberty collectives
188.8.131.52 introduces a new single collective SSH key model which makes collective administration simpler and more secure. Previously, each collective member would have its own SSH key pair and its private key would be stored in the collective repository. Now, a single SSH key pair can be shared by all members of a collective without the storage of private keys. Also, z/OS users can now use SAF keyrings for remote authentication throughout the collective.
Starting in 184.108.40.206, the single collective SSH key model is used by default. When a collective controller is created, the single collective-wide key pair is generated without having to configure or specify anything. When members join the collective, it receives the public key form the controller and adds it to its authorized keys file. Alternatively, rather than generating a new SSH key pair, users can specify an existing key pair or SAF keyring to use when creating the controller.
For more info:
Request for enhancements (RFEs) completed in WebSphere Liberty 220.127.116.11
In this release, the following RFEs were completed for WebSphere Liberty:
- RFE 100571: Enhanced Support for LDAP Certificate Filters in VMM
- RFE 113782: Logging and Tracing enhancements
- RFE 118473: Dynamic buffering of logs in memory
- RFE 67263: Enable HTTP/2 Protocol
- RFE 85967: Need JWT support in both WebSphere Application Server Traditional and Liberty
- RFE 88226: SAML single-logout profile support fro Liberty SAML Web SSO
- RFE 88201: Liberty Collective security must support the use of SAF keyrings and certificates for ssh
- RFE 88543: WebSphere Liberty Activation Spec Enhancement
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.