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:
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" /> </type-modification>
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:
