WebSphere

Subscribe to WebSphere: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get WebSphere: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


IBM WebSphere software products Authors: Yeshim Deniz, hyper filter, Timothée Bensimon, XebiaLabs Blog, Javier Paniza

Related Topics: Cloud Computing, Intel XML, XML Magazine, WebSphere

Blog Post

Updating WAS Applications In XL Deploy By @XebiaLabs | @CloudExpo [#Cloud]

Each artifact or resource is compared against what is already out on the target server, if anything

Updating WAS Applications In XL Deploy

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:

Uninstall-Re-install-Deployment

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:

UpdateDeployment

The post Updating WAS Applications In XL Deploy appeared first on XebiaLabs.

Read the original blog entry...

More Stories By XebiaLabs Blog

XebiaLabs is the technology leader for automation software for DevOps and Continuous Delivery. It focuses on helping companies accelerate the delivery of new software in the most efficient manner. Its products are simple to use, quick to implement, and provide robust enterprise technology.