What's New

Upcoming Liberty for Java buildpack changes

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.

Share this post:

Add Comment
No Comments

Leave a Reply

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

More What's New Stories

Bluemix on Stack Overflow!

Today's developers rely on search for problem resolution and how-to advice. Many of those searches land on Stack Overflow, a leader among technical community Q&A. Recognizing the importance of engaging with developers where they congregate online, the Bluemix development and support team is active on Stack Overflow, following the #bluemix tag. Some Bluemixers new to Stack Overflow wonder how it is supported versus dW Answers for Bluemix hosted here on developerWorks. Is one more "official" than the other? Are certain types of questions more appropriate for one venue versus the other?

Continue reading

Updates to IBM Eclipse Tools for Bluemix

A new version of IBM Eclipse Tools for Bluemix is now available for download. This latest version is packed with new features and improvements including JavaScript debug support for Node.js applications, Java 8 Liberty support, and trust self-signed certificates support.

Continue reading

IBM Watson Language Translation and Speech Services – General Availability

As part of the Watson development platform’s continued expansion, IBM is today introducing the latest set of cognitive services to move into General Availability (GA) that will drive new Watson powered applications. They include the GA release of IBM Watson Language Translation (a merger of Language Identification and Machine Translation), IBM Speech to Text, and IBM Text to Speech.

Continue reading