WebSphere Liberty vs. “Traditional”


Liberty is the newer, lighter-weight Java EE WebSphere server. That also gets new capabilities and specification level support faster than “Traditional WAS” (a.k.a. “tWAS” or “Full Profile”).

A few links for reference:


Having decided to at least try to get some experience with Liberty, the next step was the learning curve of how to accomplish the same things we do under tWAS. And confirm that we actually can do so. These are my notes from this exercise, for one of our representative applications.

This application is a Java EE 6, Web 3.0 application with some Apache Wink “JAX-RS” client code (before the JAX-RS spec included client APIs), including the dependence on a matching version of JAXB..


Liberty uses a single file, server.xml, to do most the WebSphere configuration that tWAS manages through many files and the admin console.

(See Directory locations and properties for a list of the files Liberty uses.)


Enable feature groups or individual features: https://www.ibm.com/support/knowledgecenter/SSD28V_9.0.0/com.ibm.websphere.wlp.core.doc/ae/rwlp_feat.html

My current set of features for this application:

    <!-- Enable features -->  

JavaEE Features

For the Liberty featureManager, I started with the javaee-7.0 feature, but that includes jaxrs-2.0, which is not what this app is using yet, and I discovered can’t coexist with jaxrs-1.1. So instead I added lower level Java EE individual features:

  • webProfile-6.0: Servlets and JSPs at EAR version 6.0 and Web application version 3.0
  • jaxrs-1.1: JAX-RS plus Apache Wink client
  • jaxb-2.2: XML and JSON mapping (Jackson), with the older version of Jackson included in tWAS 8.5.5, which the current application code depends on as well
  • concurrent-1.0: for ExecutorService for asynchronous operations
  • javaMail-1.5: for sending email

Obviously, this means that any applications I run under this particular server will only have access to those older versions of the specs. If I want an app to use newer versions, it’ll either have to run in a different server, or this app will have to be upgraded to support that newer spec level too. (I have a few other apps in this same situation.)

Additional Features:

  • localConnector-1.0 was there by default, maybe because I added the server from within RAD. I think it might be for deploying from RAD/Eclipse.
  • adminCenter-1.0 is an optional feature for viewing and potentially editing the server.xml remotely. I haven’t needed it, but wanted to see what it did.


    <!-- This template enables security. To get the full use of all the capabilities, a keystore and user registry are required. -->

    <!-- For the keystore, default keys are generated and stored in a keystore. To provide the keystore password, generate an  
         encoded password using bin/securityUtility encode and add it below in the password attribute of the keyStore element. -->  
    <keyStore id="defaultKeyStore" password="{xor}blahblah"/>

xor’ed password isn’t truly secure, so don’t share the real file or configuration line if you care to keep the password secret. It’s just mildly obscured by this format.

This file is also used, by default, as the trust store for placing the server certificates necessary to do https to remote servers. What we “Retrieve from port” into the “CellDefaultTrustStore” in our tWAS. So I had to manually add the appropriate certificates to this file, using the Java keytool command.

As the link above indicates, the Liberty “defaultKeystore” is in the server’s resources/security directory, file named key.jks.

keytool -keystore "/opt/IBM/WebSphere/Liberty/usr/servers/defaultServer/resources/security/key.jks" -importcert -file site1.der -alias site1


JAAS authentication aliases

    <!-- JAAS authentication aliases -->  
    <authData id="mydbid" password="{xor}blahblah" user="mydbuser"/>

Same bin/securityUtility script to get the xor’ed password to put in the file.


To define DB2 DataSources.

    <!-- DB2 JDBC -->  
    <library id="db2jcc">  
        <fileset dir="${lib.path}/DB2" includes="db2jcc4.jar"/>  
    <jdbcDriver id="IBMJCCDriver" libraryRef="db2jcc"/>

Where the ${lib.path} is defined in a different Liberty file, bootstrap.properties:


This is actually a “Shared Library” in WebSphere. I took this shared-library approach somewhat unintentionally, just following an example I found somewhere. It’s not the only way to accomplish this.


    <dataSource id="myappdatasource" jdbcDriverRef="IBMJCCDriver" jndiName="jdbc/myappdb">  
        <properties.db2.jcc databaseName="myappdb" portNumber="60000" serverName="dbserver"/>  


For kicking off asynchronous requests.

    <!-- ExecutorService/WorkManager -->  
    <managedExecutorService jndiName="wm/default"/>


Mail Session Object - element and attribute description in IBM Knowledge Center

    <mailSession id="myMail" jndiName="mail/myMail" mailSessionID="myMailSession" host="mymailserver.com" from="" password="" user=""/>


    <jndiURLEntry id="myUrl" jndiName="url/myEndpoint" value="https://myServer.com/myEndpointPath"/>


For tracing Wink messaging.

    <logging traceSpecification="*=info: org.apache.wink.client.internal.log.*=all: org.apache.wink.client.internal.ResourceImpl=all"/>


I actually didn’t add this manually, but let the RAD/Eclipse WDT tooling add it, by using the “Add and Remove” right-click menu option on the server.

However, I did manually add the element, so that I could add "third-party" libraries to the default library types made available to the application. Again, so that I could use the Apache Wink classes. (The other 4 were there by default after adding the `` from the RAD/Eclipse `server.xml` editor.)

    <webApplication contextRoot="/myapp" id="My Application" location="MyApplication.war" name="MY Application">  
        <classloader apiTypeVisibility="spec,ibm-api,api,stable,third-party"></classloader>  

(Thus, if I want to “remove” this app from the server, I’ll do so by editing server.xml directly and commenting out that application. If I use Eclipse tooling instead, I’ll lose this customization.)


This Liberty file contains … well… JVM-level options. For this app, a couple of System environment properties. e.g.:


We often set our JVM Time Zone to UTC, which I think would also be done here.