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 Watson Knowledge Studio to Bluemix

If you have used Watson Knowledge Studio (WKS) before, you would know that it is a powerful application to teach Watson how to interpret specific terms in unstructured text using annotation models. Available since July 2016, WKS has a broad adoption with professionals in different industries who have used it to build custom models training Watson to understand linguistic nuances in the language of their domain - cyber security, marketing, supply chain, support, and more.

Continue reading

Precise Visibility into Applications with Instana on IBM Bluemix Container Service

In this blog post we discuss how Instana integrates with IBM Bluemix Container Service to provide full visibility of your containerized applications, as they run in production. The linked tutorial was written by Pedro Pacheco, a Senior Solution Architect at Instana, with over 20 years of experience. We are excited to partner together to demonstrate how quickly and easily users can deploy a Kubernetes cluster in the IBM Cloud, deploy a sample application, and then leverage Instana’s Dynamic APM, which delivers visibility and performance management for dynamic containerized applications running in the cloud.

Continue reading

Access Trail is now IBM Cloud Activity Tracker

Activity Tracker is an IBM Cloud service that offers an integrated Cloud solution for your DevOps team and your Security team to monitor activity in the IBM Cloud.

Continue reading