Monthly Archives: August 2008

Swing Text APIs

At Ephox we are pretty heavy users of the Java text APIs. In some respects the EditLive! team probably knows more about them than anyone in the world. In a Creative Coding Afternoon recently, I was doing some work on a cool plugin for EditLive! (it might make it into a future release of Enterprise Edition), and after spending time getting angry with the Swing document (some of the anger was justified). I had an epiphany. I expect that the actual revelation will not matter to any outside of Ephox (ok so people who want to work for ephox might be interested), but I'm going to share it anyway.

The Swing Document model != the DOM. Don't expect it to look like the DOM. Don't expect it to be the HTML DOM. The subclass HTMLDocument is not the DOM. While you can access all the information in the DOM, you should not expect there to be a direct mapping between concepts in the DOM and in the Swing Document model. You can expect all the information in the DOM to be available in the Swing Document model, but it isn't going to look exactly like the DOM. The Swing Document model is a generic model for presenting a document for us in a rich text editor, which means the DOM is transformed to work with the Swing Document model.

Once you can get your head around this, the Swing Text APIs can begin to make more sense (although I'm still grumpy about the lack of working with the java.util.collections properly).

JWhich in a line of code

Old skool java programmers will have almost certainly come across the tool JWhich (http://www.javaworld.com/javaworld/javatips/jw-javatip105.html).  It's the classic tool for finding out which jar file contains a class.  The following line of code has the same effect, and is slightly better than just trying to grep jar files.

com.ibm.websphere.management.AdminService.class. getClassLoader(). getResource( "com/ibm/websphere/management/AdminService.class");1

1 – after reading the source for JWhich I realised that I have just copied it exactly :) ?

Programmatic 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<children.length;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<children.length;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?