More action with Struts 2
In a recent review of Struts 2 in Action, JW Blogger Oleg Mikheev notes that Struts 2 is "just a collection of extensions built upon WebWork, which is ultimately the right thing to learn before starting a Struts 2 project." While Struts 2 has some architectural flaws, Oleg calls WebWork well-designed, well-tested, and reliable. What are your experiences using Struts 2 and WebWork?

Also see "Hello World the WebWork way," a JavaWorld excerpt from WebWork in Action, by Patrick Lightbody and Jason Carreira.

Newsletter sign-up

Sign up for our technology specific newsletters.

Enterprise Java
View all newsletters
Email Address:
JavaWorld.com > Java Standard Edition >

A ZipClassLoader for automated application distribution

Learn how to use ClassLoaders and exploit the zip library

By Kevin Pauli, JavaWorld.com, 04/21/00

Some developers consider application maintenance an afterthought. Naturally, you tend to focus on the task at hand, which is, first and foremost, to make your program work! Sure, there might be a few minor bugs here and there, but you can always fix those in the next maintenance release, right? And no, you didn't have time to include every bell and whistle your users requested, but you can include those features in a subsequent release. When you start thinking along these lines, your project needs a maintenance plan, and the sooner the better.

For a recent Java project at IBM, my team was forced to consider application maintenance from the start. The situation had an interesting set of characteristics: First, the users were mobile and needed disconnected access to the application. Second, the users were dispersed worldwide. Third, the application was expected to evolve quickly. And fourth, the department had limited support resources to help users install upgrades.

Because the users were mobile, we needed to install the application locally on the their laptops, rather than having them retrieve the latest bytecodes from a server. Because the users were worldwide and frequent updates were expected (not to mention that we had a small support infrastructure with a limited travel budget), we needed a reliable means of remotely updating the application. We wanted something more seamless than an email with an attached jar file and installation instructions, or an executable packaged with InstallShield. The solution we implemented, which solved our problem nicely, was to store the application bytecodes in the same database the users replicate for the application data. We installed on everyone's workstation one jar we termed the bootstrapper. This unchanging piece of code locates the local database, loads the application-specific bytecodes, and launches the application. When the developers add a new report or fix a bug, we recompile the bytecodes and replace them in the database on the server. The next time users replicate their local database with the one on the server, they receive the new bytecodes along with the other new application data.

What makes this dynamic approach possible is the Java ClassLoader. A ClassLoader is the part of the JVM responsible for finding classes as your application instantiates them. Thanks to the foresight of the Java creators, you can replace the default class loader with one of your own, which loads classes in just about any way you can imagine. Any array of bytes can be interpreted as a class that your program may instantiate at runtime. The bytes may come from files in the local machine or from a server halfway around the world, delivered via a network connection. In our case, we put the bytes into a Lotus Notes database. For convenience, and to minimize the amount of replicated data, we packaged all application-specific files into a compressed zip file. The java.util.zip package lets users read and write files in the zip format.

Meet the players

In this article, I show you how we designed and developed the infrastructure for our application deployment. The components should be reusable for your own applications. Here is a brief preview of each component, which I then describe in more detail:

  • The BootStrapper: The class com.paulitech.bootstrap.BootStrapper is the main class we installed on the users' workstations to let them receive the dynamic application updates. It takes, as command-line arguments, the location of the database and the class to instantiate.

  • The Bridge: Our application at IBM happens to use Lotus Notes as the database, but yours may use something else. To decouple the choice of database from the rest of the application, I've used a common design pattern known as a bridge (as documented in Design Patterns, by Erich Gamma, et al., see Resources). All access to the database is via the abstract interfaces defined in com.paulitech.bridge. The Lotus Notes-specific implementation of the bridge interface is in com.paulitech.bridge.notes. If your database is something other than Lotus Notes, you will need to create your own bridge implementation. The interface is rather small and simple, and this task should not take long for an experienced JDBC programmer.

  • The ZipClassLoader: This is our custom ClassLoader, located in com.paulitech.classloader.ZipClassLoader, which extends java.lang.ClassLoader, the default class loader. Its constructor is passed an array of bytes, retrieved from the database, that represent the zip file. When you need a class, you ask the ZipClassLoader for the class by name. The ZipClassLoader handles all the ugly details of retrieving the proper array of bytes out of its zip file. To the outside world, the ZipClassLoader acts just like the ClassLoader that it extends. This essential component is delivered along with the BootStrapper to the users.

  • The FileInstaller: Of course, you need a tool to actually put the zip file into the database so that it may be replicated. com.paulitech.classloader.BridgeFileInstaller is an abstract class that talks to the Bridge database interface described above and writes records to it. The com.paulitech.classloader.notes.NotesFileInstaller is a concrete implementation of the BridgeFileInstaller, which, naturally, uses a NotesBridge. If you are using something other than Lotus Notes for the database, you should create your own installer tool implementation, subclassing BridgeFileInstaller, as I have done for the Notes case.



Grab on to your bootstraps

Below is a class diagram depicting what happens on the user's workstation. There's quite a bit of code, so rather than go through it line by line I will describe the algorithms with prose. The full source is available in the sample file (see Resources for a download). At this point, it would be a good idea to follow along with the source code.

Figure 1. Class diagram depicting the BootStrapper and related classes

A batch file (bootstrap.bat, in the example) kicks off the main() routine in the BootStrapper class, passing it the database location, the key that identifies the particular record that contains the bytes of interest, the name of the class you wish to instantiate as the main class, and the prefixes of any application-specific classes (separated by commas). For example, if you work for Widgets USA, all your application-specific classes start with com.widgetsusa, and you've included some custom libraries written by a business partner named Gunkle Media, whose classes are all under com.gunklemedia, this fourth parameter to the Bootstrapper should be com.widgetsusa,com.gunklemedia. The reason this last parameter is necessary is somewhat obscure, and it is necessitated by something that took me a great deal of hair-pulling to figure out. I'll explain more when I discuss custom class loaders.

Bridge over troubled data

Armed with the parameters, the BootStrapper can go to work. First, it creates a NotesBridgeFactory, which is a concrete implementation of an abstract BridgeFactory class. The BridgeFactory, as you might guess from the name, is responsible for generating a Unified Field Theorem. Just kidding! As the name suggests, its sole purpose is to create Bridge objects. What is a Bridge object? A Bridge provides an abstract mechanism for getting data in and out of your system. The core system does not actually care how the data is transferred, just that it does. The data could be going in and out of a database, could be sent and retrieved via a message queuing system, or could be transcribed by human operators onto scraps of pigeon-delivered paper. The point is, your core application talks to something that adheres to the Bridge interface and doesn't worry about the details. In this particular case, the data is ultimately stored in a local Lotus Notes database that the users replicate periodically with a server. The vagaries and peculiarities of the Notes API (and there are many, trust me!) are hidden behind the abstract interface. This allows you to change the data transport at a later time with minimal impact on your existing code.

The Bootstrapper can ask the BridgeFactory for an instance of a Bridge that corresponds to the key passed in. In this example, the file you're interested in is exampleapp.zip. The BridgeFactory (actually implemented as a NotesBridgeFactory) goes off to the Notes database and attempts to find a document (NotesSpeak for record) that matches that key. When it finds that record, it creates a Bridge (actually implemented as a NotesBridge at runtime) corresponding to that record and returns it. The Bootstrapper, using the getPayload() method of the Bridge interface, grabs the string representing the contents of the file. Notice I said "string," not "array of bytes." In a perfect world, Notes would handle raw streams of bytes better, but since Notes was designed as an unstructured document database, it does not support pure binary data. You can turn arbitrary arrays of bytes into strings and back again via old-fashioned base-64 encoding. I was able to steal -- ahem, reuse -- some nice base-64 encoding classes from org.w3c.tools.codec.

Resources