Start-Script Lobotomy

By Reimer Mellin (mellinr@yahoo.com)

Part One

Introduction

Jokingly, I sometimes compare the work of building applications to the mystical creations of the infamous Dr. Frankenstein. We reuse parts of former applications, buy or steal off the shelf libraries or frameworks and sometimes we are even forced to make field trips to ‘cemeteries’ to retrieve urgently needed parts, buried long ago. All those are  (mostly) crudely stitched together, and prematurely let loose on mankind. Sound familiar?

If your application code is the brain, then certainly Webobjects represents the nerve system to control your creation. But sometimes the nervous system does not keep up with the evolution and we are left with the options to either perform an operation or live with the painful status quo.

Being pain sensitive I chose the first option: So, Igor, let us get out our scalpels and perform some lobotomy surgery on WebObjects to teach our creations some new tricks.

The Situation

WebObjects has made great strides with its 5.x release bringing the technology into the J2EE environment with all its advantages like performance, a wealth of existing 3^rd party products and state-of-art interoperatebility. The deployment however still diverts from a pure J2EE approach and is currently solved by generating various platform specific scripts.

Especially on the NT (NT,NT2000 and XP) platform the current solution can lead to ‘interesting’ surprises, like mysterious mounted drives during run-time.

All these scripts rely on platform specific configuration files. Most importantly these files enumerate the referenced frameworks for an application.  These explicit references are usually prefixed with WOROOT, APPROOT, LOCALROOT or HOMEROOT, which are then resolved during runtime by the script and which rely on an existing deployment WOF installation. Also contained in the configuration files are application related data:

Ø      JVM invocation options

Ø      Debug Options

Ø      Application main class

Most of the work being done by the scripts is building a correct CLASSPATH string to be used for the final JavaVM invocation. Everything works fine across different deployment platforms as long as needed file locations can be expressed in terms of the known prefix directories.

Adding external jar files, resources located elsewhere or other platform specific modifications can lead to interesting juggling acts with Projectbuilder. The situation is obviously worse if you decided to not use Projectbuilder at all and instead go with Objectstyles excellent ant add-on for building wof applications.

The Idea

But wait a second …..  Why do we have to use and maintain multiple platform specific scripts anyway? For assembling a CLASSPATH? For reading a couple of simple strings from a file? Why not using a platform independent solution already at hand?

Of cause I am talking about Java itself here. Introducing WOStart, a pure Java Class and the loose equivalent of C-language cstart.o functionality for WebObjects. It puts all the former script based functionality into a single Java class and brings a lot of simplification to the deployment and launch of WebObjects Applications in general. The attached WOStart class implements the following basic steps to start a WebObjects Application:

1.      Building of correct CLASSPATH based on configuration file

2.      Setting of important Java properties for WOF Frameworks

3.      Initialization of a URLClassLoader instance

4.      Loading of Main Application class via ClassLoader instance

5.      Invocation of static void main(String[]) method

With this class at hand an invocation of any WebObjects Application merely becomes:

We assume in this example that the WOStart.class file is in the current directory and the current directory is the *.woa app directory of the application. Since WOStart relies only on the implicitly included core J2SE packages and classes, the invocation class path need only to include the location of the WOStart class itself.

The Extension    

Using Java as a platform independent tool for launching applications has one weakness though. It does not support an easy way to read environment variables and the environment variable concept in general is deprecated in J2SE as it is not platform independent. Igor solved this problem by allowing the user to specify a java property containing the path to the $NEXT_ROOT directory and by implementing a heuristic to determine it, if absent. The heuristic checks for default locations on the file system and take the first directory it finds. The name of the java property is WORootDirectory and the default command line under UNIX becomes:

Having a start class is nice and handy, but we can further ease our life by putting more intelligence into it.

One extension, which proves quite useful, is the automatic scanning for *.jar files within the application wrapper directory tree. Any found *.jar or *.zip file is added to the ClassLoader and therefore made available to the application at runtime. This allows build engineers to copy external jar files or even frameworks into the app wrapper directory, which are then dynamically resolved at run-time, regardless of the installation location of the application itself.

This is a huge win and deserves some discussion:

Ø      Now you can take referenced standard frameworks like JavaFoundation or JavaWebObjects  and copy them into a *.woa directory tree. Additionally you can take referenced jar archives and copy them into a *.woa directory tree as well. Without any change to configuration files or scripts WOStart will find the frameworks/libraries at run-time and add them to the class path. Ghee, in most cases we can even remove the configuration file altogether J. Using this approach consequently for all standard frameworks it is now possible to deploy on a machine having just a J2SE installation and NO WebObjects deployment installation at all. However, this is most likely in violation of your license and is therefore not advisable.

Ø      By copying external frameworks and jar archives into the application directory, version control of the application and its libraries/frameworks becomes suddenly straightforward.  The external Frameworks/Libraries can now be seen as private and static components of the application itself. This should make the life of system administrators simpler and that’s always a good thing™ .

The Conclusion

Our little WOStart class with less than 350 lines of code replaces ~336 lines of Unix script and ~768 lines of WINDOWS shell script (raise hands who understand THAT code!) adding some nifty functionality. It allows us to package and deploy applications in a more compact way and eases deployment dramatically by removing dependencies from platform and environment.

In the next part we will focus on adding a generic patch facility for our WOStart class, allowing us to replace (gasp!) classes from any referenced jar file or framework on demand and during runtime.

Features like the banishment of the framework file structure into a jar file suddenly become a thinkable alternative, further enhancing our more streamlined deployment experience.

We will also make WOStart into a handy little jar archive; installable in a global location, and allowing us to start applications wherever they are installed.

Reimer Mellin (mellinr@yahoo.com)                                                               07/25/2002

Reimer has extensive experience in NeXT related technologies, having worked for NeXT Software in various technical positions around the globe. He lately was the VP Engineering for a Startup and is doing currently technical and product oriented consulting work. He can be reached at mellinr@yahoo.com