WebObjects 4: Adding Third-Party Classes to a WebObjects Project

Q: I have some Java classes that I want to use in my WebObjects application, but I do not have the source code. How do I get WebObjects to recognize my Java classes?

A: Follow these steps:

1. Look in Project Builder for a Subprojects suitcase. If it is not there, use the Project-->New Subproject... menu item to create a new supbroject of type WebObjectsSubproject, named CommonJava. If there is a Subprojects suitcase and CommonJava is not listed in its browser, double-click the suitcase, choose the CommonJava.subproj directory, and add it to your project.

2. Highlight Subprojects --> CommonJava.subproj --> Resources, and drag your .jar, .zip, or .class file(s) into the Resources suitcase.

3. In your CommonJava.subproj Makefile.preamble, make sure you have the line:

JAVA_IS_SERVER_SIDE = YES

4. Edit Makefile.preamble at the top level of your project, and set OTHER_CLASSPATH.

• If you have a .jar file:
  OTHER_CLASSPATH = $(shell pwd)/CommonJava.subproj/MyClasses.jar
• If you have a .zip file:
  OTHER_CLASSPATH = $(shell pwd)/CommonJava.subproj/MyClasses.zip
• If you have a .class file:
  OTHER_CLASSPATH = $(shell pwd)/CommonJava.subproj

5. Back at the top level of your project, edit Supporting Files --> CustomInfo.plist, which should look something like this:

{
// ** Add your class paths here in the form of an array as follows:
NSJavaUserPath = (C:/MyStuff/MyApp.woa/Resources/MyClasses.jar);
}

This must be an absolute path; relative paths will not work.

6. For Solaris users only, set your LD_LIBRARY_PATH as follows:

setenv LD_LIBRARY_PATH $NEXT_ROOT/Library/JDK/lib; $NEXT_ROOT/Library/JDK/lib/sparc/native_threads

7. You're done; save the project and re-compile your application.

You need to set OTHER_CLASSPATH in Makefile.preamble to satisfy the Java compiler. However, you also need NSJavaUserPath to satisfy the Java runtime, because the third-party classes aren't statically linked into your app. You can set your CLASSPATH environment variable instead of setting NSJavaUserPath, but NSJavaUserPath is usually more convenient for deployment purposes.