Last week I posted on how to verify the cookie domain on nodes not just looking in the Ear file on the admin node. That same concept has another cool use: Verifying which VSTs the nodes actually have.

Typically one-off updates from Blackboard has us run the updateWebctEar to replace classes in the war file. In a nutshell it…

1. opens the ear
2. opens the war
3. updates the class at the path
4. regenerates the war
5. regenerates the ear

Simple enough by hand, but very convenient in a script. I was glad when Bb gave us this functionality.

cd $WL_DOMAIN
./webct.sh updateWebctEar __some_class.class webct.war/WEB-INF/path/to/class

Verifying that this is in the Ear file is rather easy, but it takes a while manually. Also, one of the steps is to open the ear then search the webct.war. Well, the managed nodes cache the Ear so it kind of saves a step to look there. We run 14 clusters and worry about inconsistencies between various development clusters and between development and production. Plus, as this is a sanity check, why not check all of them? (Also, we use dsh, so checking all 140 production nodes with one command and not having to login to each saves the most time.)

The command…

1. changes directories to a location in the cache area,
2. confirms the location
3. uses the Java ARchive (JAR) tool to list (-t) verbosely (-v) the webct.war file (-f)

All put together…

cd$WL_DOMAIN/servers/node_name_regex/tmp/_WL_user/webct/
&& pwd && $JAVA_INSTALL/bin/jar -tvf */webct.war WEB-INF/path/to/class/__some_class.class

The output looks something like below. The time stamp appears to be when the server administrator added the file to the

118864 Fri Jul 23 11:25:42 EDT 2010 WEB-INF/path/to/class/__some_class.class

I’m thinking this could also be useful to scan for what updates the nodes have in the War just after we’ve installed it.