08.15.05

Scripting Miss Websphere

Posted in J2EE at 10:38 pm by kkj

Thank God it didn’t happen on the boat - or on that mostly deserted (albeit beautiful) stretch from the north-western peninsula to the road hits the first little town on Zealand. It has been a really nice day, and being one in few lately, it did seem like a grand idea to grab a cold beer somewhere downtown. So there we go a collegeaue and me in my Peugeot, which having just had its first major regular checkup since I bought it, should be good to go for another 30.000 Km.

Not so.

Apparantly it’s not only those poor bastards who bought a 307 (combined car and lighter) who are in trouble these days. My 206 decided to drop all its coolant in the middle of Copenhagen, just as we were parking and I went thru the usual hazzle of finding a garage, calling up insurance, getting hold of ids etc. etc. and finally waiting for the tow-truck to arrive. So frankly my mood is less than perfect, and this seems like a moment of choice: I could turn gloomy, watch some ill fated movie where people get hurt and ponder the meaning of life till dawn turns the sky red again or spend my evening making the world a slightly better place for the needy Websphere developers.

Good thing I’m such a nerd

The Exciting world of JACL.

Webshere 5+ comes with a TCL scripting engine, which can be started from the command-line via $WAS_HOME/AppServer/bin/wsadmin.bat. Although somewhat slow in the acceleration, this tool will allow you to script most (if not all) of the administrative tasks that feel so daft and slow to work with via a browser. If you do your TCL well, not only will you speed-up the code-compile-deploy-and-test cycle. You are sure to get a standing applause from the rest of Websphere geek-crowd in the office, and be nominated the much appraised Websphere Productivity Award of the year. Sounds good? Read on!

Like all J(2)EE servers (isn’t that a drag?) which follow the JSR-77 specification, Websphere models its internals via JMX. Via this administrative interface you can inspect statistics and configuration parameters for servlets, EJBs, connection pools and the like, and invoke methods or change parameters to alter server behaviour at runtime. These tasks can be accomplished via wsadmin and a few dedicated objects that are readily available, when you start the tool. For a guide, check out the IBM DeveloperWorks site.

A simple, and crude script for starting an already deployed application looks like:

$AdminControl invoke [$AdminControl queryNames type=ApplicationManager,*] startApplication MyApp

Without turning this posting into a TCL tutorial I may reveal that there are really two (JMX) MBean calls involved in this statement, viz. the $AdminControl invoke command, and the $AdminControl queryNames call. Surrounded by [square brackets], the latter statements returns an “ApplicationManager” MBean of which there is only one to the outer command, which then calls “invoke” on the object passing “startApplication MyApp” as arguments. This has the effect of starting the application if it happens to be installed, and stopped. If none of these conditions are met, wsadmin will fall flat on its face with an exception.

In the heat of the code-compile-deploy-test-cycle, such behaviour becomes annoying in the long run, so let’s make the script a little more robust:

if {[isAppRunning $appName]} {
 print “$appName is already running.”
} else {
 if {[isAppDeployed $appName]} {
  print “Starting $appName.”
  $AdminControl invoke [$AdminControl queryNames type=ApplicationManager,*] startApplication $appName
 } else {
  print “$appName is not deployed.”
 }
}

The code uses two custom methods isAppDeployed and isAppRunning to make sure we don’t get those nasty exceptions, which halt the code execution. These utility methods are not standard JACL, but bundled as part of the package I wrote.

And so the complete Websphere Deployment Package (yep, this is the code, strategially located near the end of the post ) boasts the following functionality:

• Start Safe start the configured application
• Stop Safe stop the configured application
• Deploy Deploy, and safe start application
• Undeploy Undeploy and safe stop application
• Redeploy Stop, undeploy, deploy, and start or simply deploy and start depending on whether application was already deployed or not

All commands will print nice little messages in large friendly letters if anything goes wrong instead of throwing exceptions at you. You can either start them via the command line like this:

wsadmin.bat -f start.jacl

or through your build tool. We use Apache Maven and have syntax such as this in place:

<!-- Stop application -->
<goal name="stop">
 <exec dir="." executable="cmd" os="Windows XP">
  <arg line="/c ${was.home}/bin/wsadmin.bat -f src/jacl/stop.jacl"/>
 </exec>
</goal>

In order to use the commands, you will have to configure init.jacl to match your application characteristics. Basically, you will have to get a few values from the J(2)EE deployment scripts and assign them to the appropriate variables. The variables in turn are commented and should be straight forward to configure.

Best of luck getting it up and running, and trust me: That Websphere Productivity Award is within reach!

Permalink Comments