What's New

Upcoming Liberty for Java buildpack changes

Share this post:

As previously announced, we will be making two major changes to the Liberty for Java buildpack in Bluemix. Specifically, the default Liberty features for WAR and EAR applications will change from Java EE 6 Web Profile features to Java EE 7 Web Profile features and the default Java version will change from 7 to 8. Some applications might be adversely impacted by these changes. However, there are steps you can take to ensure your application will not be affected by these changes.

Default Liberty Features

When deploying WAR or EAR files, the Liberty buildpack provides a default Liberty configuration file for the application. The default configuration file enables a set of Liberty features that the application might need. Currently, that feature set provides Java EE 6 Web Profile functionality. In the upcoming Liberty buildpack v2, the feature set will enable Java EE 7 Web Profile functionality.

Specifically, the following list of Liberty features will be enabled in the default configuration:

    beanValidation-1.1, cdi-1.2, ejbLite-3.2, el-3.0, jaxrs-2.0, jdbc-4.1, jndi-1.0, jpa-2.1, jsf-2.2, jsonp-1.0, jsp-2.3, managedBeans-1.0, servlet-3.1, websocket-1.1.

The change in the default feature set might adversely affect some WAR or EAR applications due to changes in the specification levels or in their implementations. For example, if your application assumed Apache OpenJPA as the JPA provider, it may no longer work as expected since the jpa-2.1 (EE 7) feature uses EclipseLink as the JPA provider instead of OpenJPA as in the jpa-2.0 (EE 6) feature. You can see the full list of behavior changes in the Liberty profile documentation.

Please note that the applications deployed via a packaged server or server directory will not be affected. That is because the buildpack provides both Java EE 6 and 7 features and the features specified in the server.xml supplied with the application will continue to be used.

If you are deploying a WAR or EAR file and your application might be adversely impacted by the feature changes, you can configure the application to continue to use Java EE 6 features. That can be done in a couple of ways:

  1. Use a configuration override environment variable: Set the JBP_CONFIG_LIBERTY environment variable to specify a list of enabled features. For example, using the cf command-line client:
    $ cf set-env myApp JBP_CONFIG_LIBERTY "app_archive: {features: [jsf-2.0, jsp-2.2, servlet-3.0, ejbLite-3.1, cdi-1.0, jpa-2.0, jdbc-4.0, jndi-1.0, managedBeans-1.0, jaxrs-1.1]}"
    

    Don’t forget to restage your application after setting the environment variable. This environment variable can also be set in your manifest.yml file.

  2. Convert to a server directory or a packaged server: Follow the instructions to create a server directory or a packaged server for your application with server.xml that specifies the Java EE 6 features needed by the application.

Default Java Version

The Liberty buildpack v2 will use IBM JRE 8 by default. Similarly, if an application is configured to use OpenJDK as the JRE, the buildpack will default to OpenJDK 8. If version 8 of IBM JRE or OpenJDK might not work with your application, you can set Java to version 7 by setting an appropriate environment variable. For example:

For IBM JRE set:

$ cf set-env myApp JBP_CONFIG_IBMJDK "version: 1.7.+"

For OpenJDK set:

$ cf set-env myApp JBP_CONFIG_OPENJDK "version: 1.7.+"

Don’t forget to restage your application after setting the environment variable. These environment variables can also be set in your manifest.yml file. For additional information on setting the Java version and other JVM options see the Customizing the JRE documentation.

Buildpack Preview

We have made a preview of the Liberty buildpack v2 available in Bluemix as non-default buildpack. You can test your application with this buildpack by specifying liberty-for-java-new as the buildpack name when you deploy your application to Bluemix. For example, if you are using the cf command-line client to deploy your application use:

$ cf push appName -p myapp.war -b liberty-for-java-new

We have also provided a sample manifest.yml file that sets the current Liberty buildpack defaults via the environment variables. You can use this manifest file and apply to your application now to ensure it will not be affected once the Liberty buildpack v2 is released.

The Liberty buildpack v2 is due to be out on September 18th.

Add Comment
No Comments

Leave a Reply

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

More What's New stories

Bringing Continuous Delivery with Codefresh to Kubernetes on IBM Cloud

This post was co-authored with Dan Garfield, VP of Marketing at Codefresh and Full-Stack Developer.  We’re excited to partner with Codefresh and validate their technology on IBM Cloud, providing both customers sets with a consistent user experience and tool set. As a certified Kubernetes provider, IBM is one of the leaders in hosted and managed […]

Continue reading

ScyllaDB 2.0.3 with TLS now available on the IBM Cloud

ScyllaDB 2.0.3 is now available, in beta, through IBM Cloud Compose. The new release brings even more Cassandra-compatible features to Scylla, the high-performance, C++ based, in-place replacement for Cassandra. The Scylla 2.0.3 release also sees TLS encryption for clients switched on.

Continue reading