Thanks to a friendly nudge and significant contributions from Michael Wright, I have had the opportunity to reacquaint myself with an old friend - the WebSphere Liberty Profile Buildpack. In case you missed it, in a bold move IBM open sourced the WebSphere Liberty Profile their lightweight application server. Open Liberty as it is called now is an excellent landing spot for ALL current WebSphere Application Server classic apps.
To get them running with the least amount of changes WebSphere apps should typically be pushed with the WebSphere Liberty Profile Buildpack. The Liberty buildpack has myriad ways of configuring it with lots of environment variables to control the set of features and WebSphere server configuration and so on ... Here are some best practices to follow a repeatable and simple process of migrating your apps using Open Liberty to Cloud Foundry:
1. It’s OK to develop on STS or Eclipse, but don’t rely on Eclipse to package the application inside the server configuration.
2. Develop your application with Open Liberty's maven plugin. If you have an existing project convert it to Open Liberty by cloning and copying the build pom.xml from one of the guides. This is a very similar to a spring boot like experience for JavaEE/EE4J. An alternate way of developing is to configure the server.xml for your server and then keep copying the app to the dropins folder.
3. After your application runs locally package a Liberty server with your application in the dropins folder and the right server configuration in the usr directory. This is akin to packaging a fat jar for your WebSphere app. Creating a server package avoids the headache of configuring the buildpack with the right set of environment variables when pushing the app.
server package defaultServer --include=usr
4. When the application does run in Cloud Foundry play special attention to this message 2017-10-12T22:59:27.80-0400 [APP/PROC/WEB/0] OUT [AUDIT] CWWKT0016I: Web application available (default_host): http://9e1d0c1c-a318-46eb-7760-0302:8080/war-with-resource/
This informational message reveals your context-root for your application. Context root determination for an app is a multi-step evaluation based multiple files.
The context-root attribute specifies the entry point of the deployed application. The entry point of a deployed application is determined in the following precedence:
- context-root in the server.xml file
- application.xml, if an EAR application
- ibm-web-ext.xml, if a web application
- name of the application in the server.xml file, if a web application
- Directory name or the file name relative to the drop-ins directory of Liberty
My rule of the thumb is NEVER to set a context root and manage the public URL via a Cloud Foundry route. By default the buildpack set context root for an ear file is "/".
Notes of Caution
- Your application does not need to be cloud native to run on Cloud Foundry. You can push zero factor apps to CF no problem. If the application does not function correctly look under the hood by cf ssh'ing into the container and examine the final server.xml. If your EE resources are not being served or recognized by the container check your list of features and corresponding configuration in server.xml
- WebSphere Liberty Profile Buildpack provisions the DEV licensed WebSphere Liberty Profile runtime and NOT the Open Liberty runtime. To avoid licensing headaches you should fork the Liberty Profile Buildpack to provision the Open Liberty runtime instead of the DEV only licensed WebSphere Liberty Profile runtime.
In Closing
If you want to completely avoid the IBM apple cart, an excellent alternative is the TomEE buildpack which also runs JavaEE7 Full , Web and micro-profiles ear, war, fat and skinny jar apps. For more on this topic read a previous post yes-we-can.Replatforming is just the first phase of your multi-step journey to Cloud Native. Your ideal end-state is to make the app cloud native and therefore vendor and platform agnostic leveraging the app dialtone based on the contracts established by the platform API.
