Deploy Spring Boot applications on Liberty (without packaging them as a WAR) with the May 2018 beta of WebSphere Liberty. Also, bring your own JSF 2.3 implementation, custom X.509 certificate mapping updates, and customize the URL path of your OpenAPI docs.

Thanks to your support for our regular beta programme, we are able to release new Liberty features every few months. Check out the release of WebSphere Liberty which is built on the release of Open Liberty. Look out for more betas over the coming months. If you just can’t wait, take a look at the daily builds of Open Liberty.

Follow Open Liberty happenings on @OpenLibertyIO.

What’s new in this beta?

Get it now! Ask a question about the beta

Deploy Spring Boot applications on Liberty

Liberty has added support for Spring Boot applications that use Spring Boot version 1.5.x and Spring Boot version 2.0.x. With this feature Spring Boot applications can be deployed to Liberty without the need to package them as a WAR. Additionally Liberty has added tools to manage library dependencies of Spring Boot applications which allow for creating more efficient use of Docker layers for a Spring Boot application’s content.

For help, see the WebSphere Liberty Knowledge Center:

Bring your own JSF 2.3 implementation with JSF Container

Bring your own JSF 2.3 implementation (either Mojarra or MyFaces) to Liberty and take advantage of CDI integrations provided by the cdi-2.0 feature.

To bring your own JSF 2.3 implementation, package your own JSF implementation inside of your application and add the JSF Container feature to the server.xml:


And off you go!

For help, see the WebSphere Liberty beta Knowledge Center.

Customize the URL path of OpenAPI docs

The openapi-3.1 feature (introduced in the April beta) supports the MicroProfile OpenAPI 1.0 specification and provides an aggregated view of APIs from multiple applications deployed in the server.

New in the May Beta: You can now 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 /api/docs to /my/custom/docs. Similarly, the location of the rendered user interface would change from /api/explorer to /my/custom/explorer. You can now 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 /ibm/api/explorer (UI).

Speed up application start-up with Jandex indexes

If your application has many classes and is enabled for processing annotations, Jandex indexes considerably speed up the start-up of the application.

To enable Jandex indexes, add Jandex indexes to the application archives (standard location is the META-INF/jandex.idx path) and configure the server.xml:

<applicationManager autoExpand="true" useJandex="true"/>
<application name="TestApp" location="TestApp.war" type="war" useJandex="true"/>

To create Jandex indexes for your app, see How to run JBoss Jandex.

Find out more in the WebSphere Liberty Knowledge Center.

What’s already in there?

The April Liberty beta included OpenAPI 3.1 for documenting your RESTful APIs, single sign-on with JWT, and custom X.509 certificate mapping to users.

Looking for the latest?

If you’re visiting this post from the future and you’re looking for the latest releases of Liberty, here are the links you’re looking for:

Latest beta release
Latest stable release
Open Liberty downloads

Get it now! Ask a question on Stack Overflow

Join The Discussion

Your email address will not be published. Required fields are marked *