May 17, 2016 | Written by: Bobby Woolf
Categorized: Community | Compute Services
Share this post:
WebSphere Liberty is the next generation application server, available to be downloaded and installed via multiple builds so that your install contains only the components you need. You can then add additional assets to your install as needed. Once you have a customized Liberty runtime suitable for your application set up on one computer (say, your development environment) and you want to create another one like it on another computer (say, a test environment), what’s an easy way to do that? For that matter, can you bundle the application with the runtime so that you can transfer all of it to another computer in one easy step?
In this excerpt from “Java EE, the next inception: A primer to WebSphere Liberty for Java EE developers,” we’ll explore Liberty’s feature for creating a packaged server. Next, we’ll look at Liberty clustering.
To start at the beginning of this series, see WebSphere Liberty: Developing Java EE applications for the cloud.
Packaging a server
To deploy an application running in a Liberty server to a new computer (such as a production environment), it is not necessary to install an entire Liberty profile and all of the optional assets. Rather, Liberty can package a server into an archive that contains just the application, the server configuration, and (optionally) portions or all of the runtime. The packaged server only consumes disk space and bandwidth for the artifacts that need to be transferred.
Before packaging a server, you can first remove any unused features from the feature manager’s list of enabled features. If you configured the feature manager with any convenience features, replace each of those with the explicit list of features the application actually uses. A minimal set of features makes the archive, the resulting runtime, and the server they run as compact as possible.
When packaging a server, there are multiple levels of what can be included in the archive. All levels include the applications and their server configuration. The levels are:
all – Full runtime
minify – Minimal runtime
usr – No runtime
The minimal runtime doesn’t contain all of the assets installed in the runtime, only those for the features enabled in the server. Therefore, the contents of a minimal archive depend on the server’s configuration.
You can also package just the runtime without the applications:
Should you include the runtime in the packaged server? That depends on whether the target computer where you’ll unpack the archive will already have an adequate runtime installed. For example, if you want to include everything needed to run the application, include the runtime (
all level, or better yet
minify level). However, if you’re installing multiple applications in multiple servers on the target, it’s less efficient for all of their packages to include the runtime and for the runtime to be installed multiple times on the target. Instead, either one of the packages should include the runtime non-minimized, since it has to support multiple servers. Or, create a
wlp package for the runtime and
usr packages for each of the servers.
When unpacking a packaged server or runtime on a target computer, remember that the runtime does not include a JRE, so the target computer will need to have a JRE installed.
As you’ll see later, a packaged server (
usr level) is also a convenient way to deploy a Java application to Bluemix along with its server configuration.
—Bobby Woolf (@bobby_woolf)