Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Deploy Spring Boot Apps on Liberty in the May Beta

DZone's Guide to

Deploy Spring Boot Apps on Liberty in the May Beta

Spring Boot apps are now deployable on WebSphere Liberty! Check out the latest beta and see what other features have bene created.

· Java Zone ·
Free Resource

FlexNet Code Aware, a free scan tool for developers. Scan Java, NuGet, and NPM packages for open source security and open source license compliance issues.

You are now able to 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 18.0.0.1 release of WebSphere Liberty which is built on the 18.0.0.1 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?

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 Containers

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:

<featureManager>
   <feature>jsfContainer-2.3</feature>
</featureManager>


And off you go!

For help, see the WebSphere Liberty beta Knowledge Center.

Support for Custom X.509 Certificate Mapping in Liberty’s LDAP and Basic User Registries

You now have complete control over how certificates are mapped to users in the user registry.

The out-of-the-box X.509 certificate mappers for the LDAP user registry did not handle custom OID’s, parsing of certificate fields and included custom filtering of only a subset of the certificate’s fields. For example, there was no support for Subject Alternative Name (SAN). The out-of-the-box X.509 certificate mapper for the basic user registry only supported using the subject’s cn RDN for the user name. With the X509CertificateMapper API, you can now map a X.509 certificate to a user in the user registry in any way that is required.

Enabling the Custom Mapping Using the BELLs Feature

Implement the com.ibm.websphere.security.X509CertificateMapper interface and include it in a JAR. Also include in the JAR a Java ServiceLoader provider configuration file (META-INF/com.ibm.websphere.security.X509CertificateMapper) that contains the fully-qualified class names of any X509CertificateMapper implementations to be used in the Liberty server. Each implementation must be preceded by a comment line containing a key-value pair containing the key x509.certificate.mapper.id and a unique ID as the value. Use this ID to reference the implementation from the server.xml configuration file. Load these implementations into Liberty’s classpath using the bells-1.0 feature and a shared library.

Example configuration file entry:

# x509.certificate.mapper.id=basicMapper
com.mycompany.BasicMapper
# x509.certificate.mapper.id=ldapMapper
com.mycompany.LdapMapper


Example server.xml configuration for two separate X509CertificateMapper implementations to a basic and LDAP user registry:

<server>
    <featureManager>
        <feature>basicRegistry-1.0</feature>
        <feature>ldapRegistry-3.0</feature>
        <feature>bells-1.0</feature>
    </featureManager>
 
    <!--
            The library contains any X509CertificateMapper implementations.
     -->
    <library id="mylibrary">
        <file name="${shared.resource.dir}/libs/myLibrary.jar" />
    </library>
 
    <!--
            Bundle the library using the BELLS feature.
     -->
    <bell libraryRef="mylibrary" />
 
    <!--
            Reference the X509CertificateMapper(s) from the user registries by configuring the
            certificateMapMode attribute to "CUSTOM" and referencing the ID configured in the
            provider configuration file in the certificateMapperId attribute.
     -->
    <basicRegistry ... certificateMapMode="CUSTOM" certificateMapperId="basicMapper" />
    <ldapRegistry ... certificateMapMode="CUSTOM" certificateMapperId="ldapMapper" />
</server>


Enabling the Custom Mapping With a User Feature

Implement the com.ibm.websphere.security.X509CertificateMapper interface and include it in the user feature bundle. Define the X509CertificateMapper implementations as Service Components. The Service Component must specify the x509.certificate.mapper.id property which defines a unique ID as the value. The property can either be specified manually in the Service Component XML file or using the property field of the Component annotation. Load these implementations into Liberty’s classpath with the user feature. Use this ID to reference the implementation from the server.xml configuration file.

Example server.xml configuration for configuring two separate X509CertificateMapper implementations to a basic and LDAP user registry:

<server>
    <featureManager>
        <feature>basicRegistry-1.0</feature>
        <feature>ldapRegistry-3.0</feature>
        <feature>usr:myFeature-1.0</feature>
    </featureManager>
 
    <!--
            Reference the X509CertificateMapper(s) from the user registries by configuring the
            certificateMapMode attribute to "CUSTOM" and referencing the ID configured in the
            Service Component in the certificateMapperId attribute.
     -->
    <basicRegistry ... certificateMapMode="CUSTOM" certificateMapperId="basicMapper" />
    <ldapRegistry ... certificateMapMode="CUSTOM" certificateMapperId="ldapMapper" />
</server>


For more info, see the WebSphere Liberty Knowledge Center docs on Basic registry mapping and LDAP registry mapping.

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

 Scan Java, NuGet, and NPM packages for open source security and license compliance issues. 

Topics:
java ,spring boot ,liberty ,app deployment

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}