Getting Jython Modules to Work with the WebSphere wsadmin Tool.

I just finished wrestling with a problem for a day and a half – I’m writing down the solution for your benefit.  I’m not going into excruciating detail because I don’t understand it all.  This is just a quick look at the problem and what worked for me.  I hope it saves a little bit of time for a few people.

The Context

I am working on a set of scripts that I will use to automatically deploy a JEE EAR file to an IBM WebSphere version 7.0 (WAS 7) application server.  Even so, I believe this blog applies equally well to deploying a WAR file and on version 6.1 – 7.0 of WAS.  I am using a combination of Windows batch scripts, Ant scripts and Jython scripts.  The Jython scripts are being run through the wsadmin tool to do the WAS admin work.  I am setting the deployment scripts up in both a test and production environment.  The test environment is deploying from an automated build, which uses Ant to start the deployment process.  The production environment does not use Ant.  In both environments, there is a batch script that passes a Jython script to the wsadmin tool, where the Jython script does the actual WAS admin work (e.g. starting/stopping servers, deploying code and saving the configuration).

So to summarize, there are two deployment scenarios:

1. An Ant script, via the exec task, calls a Windows batch script, which runs the wsadmin tool with the necessary parameters, one of those parameters being a Jython script that does the deployment work.
2. A Windows batch script (which is part of another automated scheduling system) calls another Windows batch script, which runs the wsadmin tool with the necessary parameters, one of those parameters being a Jython script that does the deployment work.

The Problem

Once you’ve gotten jaded enough on IBM products and other such “enterprise-level tools”, the above setup is “basic”, so I’m assuming you’re just as twisted as I am and am not going to explain it further.  My actual problem is that I have written a Jython module that I want to use in my Jython deployment scripts.  Python, and thus Jython, is just like Java in that it has a specific route it follows when searching for referenced modules.  In regular Python programs the environment variable that is analogous to Java’s CLASSPATH is called PYTHONPATH.  The idea is exactly the same in both languages, the Python runtime has to know about all the directories where you expect Python modules to be in order for it to find them.  The same is true for Jython, although you have to setup the path a little differently since you’re running on the JVM.

All this isn’t complicated, but the wsadmin tool does make it harder to deal with.  The wsadmin tool sets up a very particular environment for itself, which is what tripped me up for so long.  Not to mention the muddled mess of running Python, via Jython, via the wsadmin tool, via a batch script, via an Ant script.  I was having a lot of trouble in actually importing my module because I did not have the Python path setup correctly, even though all of my Jython files were in the same directory.  If you have a Python file in the same directory as another module you are importing, you don’t have to do any special setup for Python to resolve the import.  However, with Jython and the wsadmin tool, your Jython files are being run out of the directory where either the JVM or wsadmin tool are being executed from, respectively.  This means that you have to setup the Python path, even if all of your Jython files are in the same directory.

The Solution(s)

It turns out that this is easy to solve, you just have to setup the Python path.  That seems obvious now, but since Python seems to handle module resolution fine in the same situation, it was confusing that Jython doesn’t.  An alternate solution is to be explicit about where the wsadmin tool should execute.  I ended up using each solution, one for the test environment and one for production.  In the test environment, where I’m starting with an Ant script, I’m using the dir attribute of the exec command to specify where to execute the command from.  This keeps the working directory for the wsadmin tool in the same place where my Jython scripts reside and allows the Jython runtime to find my referenced modules.  By “working directory” I mean the directory from which the wsadmin tool is actually executed. Without the dir attribute specified, the wsadmin tool will run in a different directory (the directory where the wsadmin.bat file is installed, I believe) and my Jython files will not be on the Python path.  Here’s an example of the Ant task:

<!-- The dir attribute is VERY IMPORTANT and allows the Jython scripts to import other scripts from this directory.-->
<exec executable="${env.WORKSPACE}/wasscripts/DeployWebServiceToCluster.bat"
      failonerror="true"
      failifexecutionfails="true"
      dir="${env.WORKSPACE}/wasscripts"
>
  <env key="WSADMIN_HOME" value="${env.WSADMIN.7.HOME}"/>
  <arg value="${wsadmin.props.file}"/>
  <arg value="${env.WORKSPACE}/wasscripts"/>
  <arg value="${env.WORKSPACE}/dist/${ear.file.name}"/>
  <arg value="${was.dmgr.name}" />
  <arg value="${was.cell.name}" />
  <arg value="${was.cluster.name}" />
  <arg value="${ant.project.name}"/>
  <arg value="${was.user}"/>
  <arg value="${was.user.password}"/>
</exec>

For the production environment I took the simpler route of passing in the Python path to the script that starts the wsadmin tool.  The wsadmin tool allows you to do this with the command line parameter -javaoption.  Here’s an example of what I did in the Windows batch script:

@rem %1 - Absolute path to the properties file.
@rem %2 - User with admin access to the WAS deployment manager.
@rem %3 - Password for the admin user.
@rem %4 - Absolute path to the Jython scripts folder.
@rem %5 through %8 - Parameters passed to Deploy_To_Production.py (see file for details).

call "%WSADMIN_HOME%\wsadmin.bat" -p %1 -user %2 -password %3 -javaoption "-Dpython.path=%~4" -f %4/deploy/Deploy_To_Production.py %5 %6 %7 %8
set ERRORLEVEL=%MYERRORLEVEL%
exit /B %MYERRORLEVEL%

The most crucial part is the -javaoption “-Dpython.path=%~4”.  Notice first that the entire value of the -javaoption parameter is enclosed in quotes.  It seems that you have to do this to get it to work correctly when passed to the JVM that gets started to run your Jython script. Since the entire value for the -javaoption parameter is in quotes, I’m using the Windows batch script trick (%~4 as opposed to just %4) to remove quotes from the fourth parameter to the batch script.  As an example, if the path passed into the batch script above as parameter four is

C:\temp

%4 will produce

"C:\temp"

whereas %~4 will output

C:\temp

This is also necessary to get things to work correctly.

Conclusion

I realize that there are many holes in my explanation.  The point is to briefly convey how to solve this problem if you should get hung up on it too.  I’m continuing to learn more about how to use Jython with the wsadmin tool for WAS scripting, so feel free to ask for clarification or about related problems.  Helping you will give me a chance to learn more as well.  Also, I found a pretty good blog about wsadmin scripting while I was researching this problem.