Download Liberty 17.0.0.2 Ask a question on Stack Overflow

What’s new in this release?

Liberty Updates

Social Login feature

Social login is a form of single sign-on (SSO) that enables users to sign in to a website by using their existing social media account instead of creating an account specifically for the website. You can configure a Liberty server so that users can authenticate to websites that are hosted on the Liberty server by logging in with their social media accounts. Choose from the predefined social media platform configurations, or define your own configuration for any social media platform that is based on the OAuth 2.0 or OpenID Connect 1.0 standards.

This is enabled by the socialLogin-1.0 feature. You can configure social login for one or more of the following social media platforms: Facebook, GitHub, Google, LinkedIn, Twitter and any OAuth 2.0 or OpenID Connect 1.0 social media platforms.

Configuration includes three steps:

  • Register your Liberty server on the social media platform, acquiring an application ID and secret if needed. For example, here are the instructions for Facebook.
  • Add a social media configuration element (e.g. facebookLogin) in server.xml and configure it with the application ID and secret.
  • Import the social media endpoint’s certificate into the Liberty server’s trust store.

JPA container feature update

The jpaContainer-2.1 feature provides a JPA container implementation without limiting you to the core JPA function in EclipseLink. You can plug in any version of any third party JPA persistence provider implementation that is compliant with the JPA 2.1 specification, including EclipseLink with extensions like MOXy and JPA-RS.

Audit feature update

You can now upgrade from the non-warranted (ILAN) version of Liberty to a supported (IPLA) Liberty Core edition. You can easily take the zips from WASdev, develop with them, create server packages and easily apply a license and deploy them into production.

Moreover, if necessary, you can now apply a license archive to switch from an edition with a more advanced feature set e.g. Network Deployment to an edition with a more basic feature set e.g. Liberty Core.

API Discovery feature update

This feature updates the Swagger libraries that are part of the apiDiscovery-1.0 Liberty feature to their most recently released open source levels.

The Swagger libraries, UI and code generation tool have been updated to their latest levels to match the current development experience with open source. This includes fixes and enhancements up to Swagger-core v1.5.12.

The API Discovery feature in Liberty provides native Swagger 2.0 support for web applications, which means that you don’t need to include any third-party JAR files in each of your applications to use the Swagger annotations, nor do you need to deploy and manage a separate Swagger UI application.

In 17.0.0.2 we have upgraded Liberty’s Swagger packages to the latest versions available on Open Source, allowing you to take advantage of the latest annotations and recent functionality additions to the UI (such as the improved authorization flow). We have also picked up dozens of bug fixes from the Open Source community. So in summary, a more modern and stable API experience!

For more information, please see our Knowledge Center or our WebSphere Connect hub, which contains various links to videos, blogs and tutorials related to the API Discovery feature.

Time Counter feature

A UseTime counter attribute has been added to the ConnectionPool MXBean. This new counter will make it easier for users transitioning from traditional WAS to Liberty because it provides similar functionality.

Please see the Knowledge Centre for more information.

JDBC 4.2 support

You can now configure and use JDBC drivers that meet the 4.2 MR (maintenance release) specification. This spec is backwards compatible with the 4.1 spec.

Admin Center feature updates

The Java Batch tool of the Admin Center (the adminCenter-1.0 feature) added Purge to the list of actions for job instances. Purge deletes all database entries and, optionally, deletes job logs associated with the job instance.



Restart of a job instance from the Java Batch Tool was enhanced to allow editing of job parameters instead of simply reusing the parameters from the previous execution. Parameters can now be added, removed, and edited.


Additional search criteria was enabled to filter information about job instances displayed on the Java Batch tool dashboard. Filtering now includes case insensitive searches for submitter, application, and batch job name. A wildcard character (*) can be entered into the search value for these fields. Also added was a filter for last update range to display active job instances between the specified dates.


All search criteria, except for dates, can be easily selected from values displayed in the Job Instance table.


Or, using the filter autocomplete typing and suggestion popup feature, place the cursor within the filter box area and begin typing to quickly see a list of valid matching filter values to select from for entering search criteria.


For each search ‘pill’ in the filter box area, an ‘x’ button was added which will remove that search criteria from the current filter box area. Afterwards, select the
 button to re-filter the list of job instances with the new criteria.


Deploy tool updates

The Java Batch tool was also updated to now persist user tool data, such as which columns to display within the tables or the maximum number of job instances to fetch for each filtered query made, to the server. Previously this data was stored as a browser cookie. Now these settings will follow the user even if they switch browsers or computers.

For Liberty Server Package and Node.js Application Package deployments where the package being deployed is not local to the target host, the remoteFileAccess permission for the target host(s) is no longer required.

When a user browses for a file or drags a file to drop onto the Deployment Parameters section, the Package directory field for the Liberty Server Package deployment rule or the Application directory field for the Node.js Application Package deployment rule is grayed out and is no longer required or used.


WebSphere Developer Tools (WDT) updates

Rapid development using the Liberty Maven plugin and WDT for Eclipse

We’ve made significant updates to the liberty-maven-plugin and Eclipse tools to improve the developer experience when working with WebSphere Liberty in a Maven environment. The liberty-maven-plugin has been updated to include Loose Application support for web applications that enables the WebSphere Liberty runtime to process updates lightning fast! The Eclipse tools can now detect Maven web application projects that are configured to work with the new liberty-maven-plugin and can automatically create a server in the workbench. You can then iteratively develop and debug your web application within Eclipse and then build and package your application using Maven. The end result is a cohesive Maven development experience.

To try out the new experience simply follow these steps:

  • Use the following command to generate the sample project from an archetype:
    mvn archetype:generate -DarchetypeGroupId=net.wasdev.wlp.maven -DarchetypeArtifactId=liberty-archetype-webapp -DarchetypeVersion=2.0 –DwlpPluginVersion=2.0 -DgroupId=ServletSample -DartifactId=ServletSample -Dversion=1.0

  • Import your project into the latest WDT using File > Import… > Existing Maven Projects

After importing your project a dialog will prompt you to select whether you would like to automatically create a server in the Servers view with your application already published.


You can now efficiently develop your application within the workbench whilst reaping the benefits of Maven.

Here are some things you can try:

  • Run your web application by opening the context menu on a resource in the Project Explorer view and selecting Run As > Run On Server
  • Make updates to an application resource and see the server pick up the changes on-the-fly
  • Debug your web application by setting a breakpoint in your code and using the Debug As > Debug On Server action
  • Perform actions like Start, Stop, and Open Log Files on the generated server in the Servers view
  • Use the Servers view to see a clear representation of the server configuration files within your Maven project. The files listed under the Maven Target folder are derived from your Maven project’s target folder. These files are intended for read-only consumption. To make updates to your server’s configuration use the files that are listed directly under the server that correspond to the files in your Maven project’s src folder
  • If you run mvn clean, or any other goal from within the workbench that causes the Liberty files to be deleted, the server and its associated runtime will be automatically removed from the workbench. Running mvn install or one of the liberty-maven-plugin goals that re-install the server will reinstate the server in the Servers view. Note: Maven commands executed from outside of Eclipse will require refreshing the Project Explorer view in order for the workbench to process the changes
  • Make changes to your liberty-maven-plugin configuration in your Maven project’s pom.xml and use the Maven > Update project… menu option to update the server and runtime instances within the workbench

Further WDT updates

Projects with a location outside your Eclipse workspace can now be deployed to a Liberty Docker server when running applications directly from the workspace.

This means that you can use the running applications directly from the workspace with a Liberty Docker server even when your projects are imported from a local git repository. If you deploy one of these projects to the server it will automatically create a new container with the volumes needed to access that project and other projects in the same directory locally.

For supporting projects with a location outside of the workspace:

If a project is imported into the Eclipse workspace without copying it, such as importing a project from a local git clone then the location of the project is not in the Eclipse workspace folder. In previous versions, only projects located within your Eclipse workspace folder could be deployed to a Liberty Docker server with “running applications directly from the workspace” enabled. Now projects that are not located in your Eclipse workspace folder can also be deployed. When you deploy such a project to the server it will ask you if you want to create a new container with the additional volume needed to access the project from within the container. A commit will be created on your current container and a new container will be created from the image with the additional volume. This way nothing you have done so far will be lost. Your project will then be deployed on the new container and you can run it and modify it taking advantage of the faster response times associated with running applications directly from the workspace.


Download Liberty 17.0.0.2 Ask a question on Stack Overflow

Migration Toolkit updates

The Migration Toolkit for Application Binaries (binary scanner) continues to be enhanced in order to assist application developers and administrators with application migrations. Both the Eclipse-based source scanner and binary scanner contain bug fixes and a few new rules. Also, the Java SE rules were revisited for their complexity and severity. Many of the Java SE rules flag behavior changes that are unlikely to affect existing applications, and that can only be assessed after deploying the application. Therefore, the severity of many of the rules have been downgraded, and many have been changed to flag once per Eclipse project or archive. This provides a more accurate assessment of the Java SE migration effort.

The new Application Migration Report makes it easier than ever to analyze your application binaries for migration to later releases of WebSphere traditional or Liberty. This report combines the content of the Application Evaluation Report (--evaluate), the Detailed Migration Analysis Report (--analyze), the Application Inventory Report (--inventory), and the feature list XML file (--featureList). The Application Migration Report is generated with the --all action, which is the new default action. The Application Evaluation Report can still be generated by specifying the --evaluate action explicitly.

The Detailed Migration Analysis Report is redesigned to organize rule results by severity and then category. This makes it easier to navigate the report and find the rules that interest you the most.

The Potential Deployment Problems section of the Application Inventory Report now contains information on archives with system level Java virtual machine (JVM) configuration. Certain JVM configuration settings, when set by an application, can cause server-wide issues because the system properties apply to the entire JVM.

The --featureList action added support for the --includePackages and --excludePagkages options. These options affect which class files are analyzed, and provide more flexibility during feature list generation.

Finally, the --format=txt option is no longer supported. Check out the --format=json support instead, which provides report content in a format ready for easy data analysis.

Get the Eclipse-based tools! Get the command-line tool!