Using Jython with WebSphere Portal

Most developers and administrators working with WebSphere Application Server (WAS) know that both JACL and Jython languages can be used for various WAS administration and configuration tasks. However, JACL has always been a preferred choice, simply because this is the default language used by the product's admin tool (wsadmin) and also because JACL examples and documentation are more complete.

Using JACL might have been a valid option just a few years back (when WAS just came out) given the uncertainty surrounding the Jython project. Today, however, jython is clearly alive and well; an alpha version supporting Python 2.5 was announced recently. Therefore there is really no point in using JACL any longer, except may be for shops with a large collection of existing JACL scripts. JACL syntax is quite arcane compared with Python and the language is clearly not as widely used.

IBM confirmed this view by releasing JACL to Jython converter a couple years back.

Unfortunately, up until recently, jython was not officially supported in another IBM product, WebSphere Portal, which comes with wpsript tool for managing pages, deployable modules and other portal artifacts.

But since portal scripting relies on wsadmin's shell, jython is in fact fully supported by the product, it's just not documented. All that you need to do to switch to jython is to invoke wsadmin with "-lang jython" and "-wsadmin_classpath " followed by the list of portal jars (you can copy the classpath from SCRPATH variable definition in wpscript.sh).

As an example, I put together a simple Jython script for cleaning up a page hierarchy. Removing pages before applying an XMLAccess script with page definitions allows to start portal configuration from a clean "known" state. Very often, especially in a development environment, an application's page hierarchy gets polluted with various "test" pages created by developers. The script gets rid of them.

In WebSphere Portal 6.1 Jython is finally made a first-class citizen. The product's documentation proclaims that JACL support will be phased out and that jython is the way to go. Surprisingly, though, all examples still use good old JACL. I assume it's just a matter of time before they convert.

Use simple code to Check for WebSphere Portal iFixes and Fixpacks

As the internet didn't seem to know how to programatically lookup the installed iFixes and Fixpacks for a PortalServer, I'm going to share my solution, it the hope that someone can point me to a better way.

What I was able to work out from trawling the net and poking around at the WebSphere portal installation is that the install history for iFixes and Fixpacks for Portal are stored in the directory %PORTAL_HOME%/version/history. This makes the process of finding the fix level a case of:

1. Lookup the Portal home.
2. List the files in the version history directory.

Lookup the Portal Home

To lookup the portal home, use the fact that there is a WPS_HOME environment variable set in the WebSphere environment. Unfortunately looking up values in the WebSphere environment is non-trivial. The WebSphere environment is not made directly available, to access it you need to go through the WebSphere Admin service, and the WebSphere management mbeans.

The code to do this is:

com.ibm.websphere.management.AdminService as =
com.ibm.websphere.management.AdminServiceFactory.getAdminService();
String server = as.getProcessName();
javax.management.ObjectName serverName =
new javax.management.ObjectName("*:*,type=AdminOperations,process=" + server);
Set objectNames = as.queryNames(servName, null);
javax.management.ObjectName objectName =
(javax.management.ObjectName) objectNames.iterator().next();
Object[] args = new Object[] {"${WPS_HOME}"};
String[] signature = new String[] {"java.lang.String"};
String wpsHome = as.invoke(objectName,"expandVariable",args, signature);

The wpsHome variable will contain the string path to the websphere portal home directory.
List the Files in the Version History Directory

After retrieving the portal home, it is possible to lookup the fixpacks in the ${WPS_HOME}/version/history directory.

The following code does this:

File f = new File(wpsHome + File.separatorChar +
"version" + File.separatorChar + "history");
String[] children = f.list();
for (int i=0;i out.println(children[i]);
}

In summary the full code snippet for this is:

com.ibm.websphere.management.AdminService as =
com.ibm.websphere.management.AdminServiceFactory.getAdminService();
String server = as.getProcessName();
javax.management.ObjectName serverName =
new javax.management.ObjectName("*:*,type=AdminOperations,process=" + server);
Set objectNames = as.queryNames(servName, null);
javax.management.ObjectName objectName =
(javax.management.ObjectName) objectNames.iterator().next();
Object[] args = new Object[] {"${WPS_HOME}"};
String[] signature = new String[] {"java.lang.String"};
String wpsHome = as.invoke(objectName,"expandVariable",args, signature);

File f = new File(wpsHome + File.separatorChar +
"version" + File.separatorChar + "history");
String[] children = f.list();
for (int i=0;i out.println(children[i]);
}

The work of mapping file names to the installed fix packs/iFixes is left as an exercise for the reader.

Does anyone know if there is a better way of dong this?