Updating WAS Applications In XL Deploy

| January 8, 2015 | 0 Comments

Some users of WebSphere Application Server prefer to upgrade their EAR/WAR applications using WAS’s “update-in-place” option instead of uninstalling it and then re-installing. The latter, of course, is XL Deploy’s default behavior, but it can be changed with a simple tweak to a type definition in an XML file.  Here is a look at how the WAS Admin Console presents these options:

WAS Admin Console showing Install, Uninstall and Update options

The WAS Admin Console offers Install, Uninstall and Update options (among others) for managing Enterprise Applications

But before we describe the tweak, let’s take a closer look at XL Deploy’s analysis of a deployment. Each artifact or resource is compared against what is already out on the target server, if anything.  Then XL Deploy assigns one of four possible actions: create, destroy, modify or noop. Noop, of course, is no-operation, for the case of no changes.

XL Deploy has pre-defined behavior for create and destroy when working with EAR/WAR files, and invokes a python script for each of these. Expanding the WAS plugin JAR file reveals these as deploy-application.py and undeploy-application.py. But the operation that pertains to this scenario is modify: the user wants to replace an EAR or WAR with an upgraded version. As there is no specific “modify” behavior defined, XL Deploy executes a destroy and then a create operation, first uninstalling the old module and then subsequently installing the new one, as in steps 2 and 4 in this deployment steplist:


The result is a “clean” installation — nothing is carried over from the previous installation of the app, and this is a good way to fight configuration drift. However a user who wants complex applicaton configuration settings carried forward will want to opt for update-in-place even if this approach violates the spirit of XL Deploy’s design philosophy — any deployment package be a complete incaranation of the application that is deployable to any environment, whether a first-time deployment or update.

To override the modify behavior, we simply define a modifyScript property on the War or Ear type:

<type-modification type="was.WarModule">
<property name="modifyScript" default="demo/update-application.py" hidden="true" description="Replace an entire installed application" />

and then we build the script in the location given, using wsadmin’s scripting language and a couple of handy resources supplied via the “deployed” object:

# demo/update-application.py
AdminApp.update(deployed.name, 'app', '[-operation update -contents %s ]' % deployed.file)

And now the update step replaces the uninstall/re-install behavior:


Dave Roberts

About the Author ()

Dave is a Sales Engineer for XebiaLabs based in Boston, MA. He has worked on both sides of DevOps, as a web software engineer and as a WAS/DB2 administrator.