Simplifying WebObjects application deployment

Framework Embedding

Framework embedding allows the WebObjects application and all supporting frameworks and jar files to be deployed inside the WebObjects application folder.  This can allow a WebObjects application to be fully self contained, even to the point of containing the WebObjects deployment environment.

This capability is implemented as a set of patches to the woproject ant tasks (www.objectstyle.com/woproject), currently on the woproject-1.0b release.

How it Works

Presently, a WebObjects application is started by a shell script inside the .woa directory that constructs a classpath from a class path file which contains a list of paths to .jar files.  The entries in the file are absolute pathnames, with 4 defined prefixes: APPROOT, WOROOT, LOCALROOT and HOMEROOT.  This allows some portability for the deployment of the .jar files, for example all the WebObjects frameworks are referenced through the WOROOT prefix.

By copying all supporting frameworks into the .woa wrapper into the directory Contents/Frameworks/ and adjusting the entries in the class path files to start with APPROOT, the script will construct the class path to include the full path to the framework relative to the .woa directory.

The same can be done with third-party jar files and also with the WebObjects distribution itself: this makes the WebObjects application fully self-contained, and runnable on any machine that supports a supported JVM.

Benefits

- The WebObjects application is fully self-contained, which means simpler deployment.
- Since the included frameworks are in essence private to the application, you won't run into version mismatch issues when an external framework is changed.
- Upgrading the WebObjects frameworks won't mysteriously break an already deployed application.
- No issues concerning .jar files installed in the ext directories in the JDK on deployed systems.

Changes to WOProject

The visible changes are to the WOApplication task.

- addition of an embedStdFrameworks attribute in woapplication.  If this is set to true, the WebObjects system frameworks are copied into the .woa directory.  Setting this forces stdFrameworks to be set to true.

- addition of an embed attribute to the frameworks entry.  If this is set to true, all the included frameworks in the entry will be copied into the .woa directory.

- addition of a lib entry.  Any included .jar files will be copied into the .woa directory.  This exactly matches the lib entry in woframework.

Setting the embed attributes will force the entries in the class path file to be written relative to the APPROOT prefix.

There are other changes to existing functionality.

- the root attribute of the frameworks entry has been expanded to support absolute paths along with the wo.woroot, wo.localroot and wo.homeroot. (this is now in the woproject base code [8/7/2002]

- You can specify the rest of a path after the wo. elements.  For example, root="wo.localroot/Library/Frameworks".  Also, the framework names specified within the frameworks entry must just be the framework name itself, eg <include name="Foo.framework">.

Examples

Here's a build.xml file done in the normal way.  This application hypothetically depends on a framework installed in the local library frameworks directory called TestFramework.framework, the standard WebObjects frameworks, and on a third-party jar file that is likely installed in the Java ext directory (/Library/Java/Extensions under OS X).  If we want to deploy this application on a Q/A or production system, we'll have to install WebObjects on those machines, copy the TestFramework.framework onto those machines, and make sure that the third party jar file is correctly installed in the extensions directory on the target machines.

<target name="package">

  <woapplication name="Test" destDir="../install" stdFrameworks="true">
    <classes dir="build"/>

    <resources dir=".">
      <include name="*.api"/>
      <include name="*.wo/**"/>
    </resources>

    <frameworks root="wo.localroot">
      <include name="Library/Frameworks/TestFramework.framework/**"/>
    </frameworks>

   </woapplication>

</target> 

Here's the same application built with all the frameworks and third-party jars installed into the application folder.

<target name="package">

  <woapplication name="Test" destDir="../install" embedStdFrameworks="true">
    <classes dir="build"/>

    <resources dir=".">
      <include name="*.api"/>
      <include name="*.wo/**"/>
    </resources>

    <frameworks root="wo.localroot" embed="true">
      <include name="Library/Frameworks/TestFramework.framework/**"/>
    </frameworks>

    <lib dir="../../lib">
      <include name="3rdpartyjar.jar"/>
    </lib>

   </woapplication>

</target>

Now, just copying the Test.woa application to another machine will ensure that all dependent frameworks, libraries and resources will be copied as well.

Pure Java startup

This is based on Reimer Mellin's work to create a Java class which replaces the scripts that currently start up the WebObjects application.  This is called WOStart, please contact rmelli..ac.com