Skip to main content
DevOps icon showing cogs

This post is from the XebiaLabs blog and has not been updated since the original publish date.

Last Updated Jan 07, 2015 — DevOps Expert

Updating WAS Applications In XL Deploy

DevOps

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:

[caption id="attachment_8397" align="alignnone" width="300"]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[/caption] 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:Uninstall-Re-install-DeploymentThe 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:UpdateDeployment

More from the Blog

View more
Ascension Launch Banner
Apr 26, 2022

Get ready for peak performance with Digital.ai’s newest AI-Powered DevOps Platform Ascension Release

DevOps
Today, Digital.ai is excited to announce our latest AI-Powered DevOps ...
Read More
Jan 24, 2022

Digital.ai Value Stream Delivery for SAFe®: The key to amazing business outcomes

DevOps
The Scaled Agile Framework (SAFe) is the world’s leading framework for ...
Read More
Dec 09, 2021

How SaaS and cloud-based solutions helped the U.S. Department of Veterans Affairs achieve digital transformation

DevOps
Modernizing legacy systems was an ongoing goal for the U.S. Department ...
Read More
Nov 29, 2021

Increase velocity and reduce risk with AI and machine learning

DevOps
Artificial Intelligence (AI) and machine learning (ML) have proven use ...
Read More
Contact Us