There seemed to be a lot of interest in load-testing WDK applications with something other than Mercury LoadRunner. Here is an article I wrote that gives an introduction on using Apache JMeter to perform load-tests against Documentum WDK applications.

Although steeply-priced at $2495, the annual EMC Documentum Developer Conference offered in-depth looks into the forthcoming 5.3 sp1 release (due out tomorrow) and access to Documentum product managers and engineers. I’d estimate about 300 developers from around the world attended the four day conference in Berkeley.

Release 5.3 sp1 promises to be pretty major, as far as service packs go. Many of the features that didn’t make it in to 5.3 due to time constraints are included in the service pack. That’s contrary to the normal EMC Documentum practice of limiting service packs to bug fixes with only minor changes or additions to functionality.

From my perspective, one of the most anticipated features is the next generation of the Business Objects Framework, BOF 2.0. The ability to hot-deploy and sandbox BOF Type Based Objects (TBO’s) and Service Based Objects (SBO’s) is high on my list. There’s also a new package of Search interfaces that look interesting.

This release will be the first in which Linux is supported across the stack. Release 5.3 installed without issue on my Red Hat Linux Enterprise 3 VMWare image. Customers already familiar with content server installations on other flavors of Unix should not have a problem.

I’m in Berkeley for the Documentum Developer Conference. Spent a wonderful evening over at my aunt and uncle’s house in El Cerrito. Great dinner and lots of fun catching up. The Claremont Hotel & Resort, the venue for the conference, is pretty sweet.

When you create custom Java methods for Documentum’s Java Method Server you can add the class or JAR files to $DOCUMENTUM/dba/java_methods and they’ll get added to the Java Method Server’s classpath automatically. However, if those methods leverage BOF classes, you may need to do some tweaks so that the Java Method Server can load those classes.

Currently, our preferred approach for telling the content server where our custom classes live is to create a directory off of $DM_HOME, let’s call it nav/lib for this discussion, in which our JARs live. We then create a JAR that only contains a manifest, we’ll name it nav.jar, in $DM_HOME. The manifest points to the JARs in nav/lib. This enables us to have a single file in the classpath, nav.jar, with as many additional JARs in nav/lib as we need and we only have to update the manifest file in nav.jar when we make changes rather than changing the classpath.

Documentum does this as well. That’s what dctm.jar is all about. It contains no classes. Only a manifest. Here’s what’s in the dctm.jar’s manifest.mf:

Manifest-Version: 1.0
Created-By: Documentum Installer Component Library
Class-Path: Shared/dfcbase.jar Shared/dfc.jar Shared/bsf.jar Shared/lo
 g4j.jar Shared/xalan.jar Shared/xercesImpl.jar Shared/xmlParserAPIs.j
 ar Shared/xml-apis.jar Shared/All-MB.jar Shared/ldapjdk.jar Shared/ld
 apfilt.jar Shared/jss311.jar Shared/certj.jar Shared/sslj.jar Shared/
 jsafe.jar Shared/jnet.jar Shared/ldap.jar Shared/ldapbp.jar Shared/jn
 di.jar Shared/bpmutil.jar Shared/ci.jar Shared/subscription.jar Share
 d/workflow.jar Shared/xforms.jar Shared/dam_services.jar Shared/tar.j
 ar Shared/wcm.jar Shared/WcmMethods.jar

An easy way to create a JAR with only a manifest is to use the Ant jar and netsted manifest tasks, like this:

On UNIX servers, the Java Method Server is started manually using Tomcat’s startup.sh script. There are many ways to tell Tomcat about classes you want to share across webapps. The way Documentum does it (and therefore, the technique we’ve copied) is to update setenv.sh to include dctm.jar (or in our case, nav.jar) in Tomcat’s classpath.

When your content server runs on a Windows host, however, the Java Method Server is started as a service which calls tomcat.exe. If you want to use a similar approach as described above, you can use regedit to update the registry so that the right arguments are set when tomcat.exe is run. In this case, the classpath needs to be updated to include nav.jar.

The key you need to update is HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DmJavaMethodServer\Parameters. On my content server the classpath argument was in the string named JVM Option Number 0. I updated mine to include nav.jar, like this:

-Djava.class.path=C:\Program Files\Documentum\tomcat\4.1.27\bin\bootstrap.jar;C:\Program Files\Documentum\jdk\131_04\lib\tools.jar;C:\Program Files\Documentum\dctm.jar;C:\Documentum\Config;c:\program files\Documentum\nav.jar

After you make the change, restart the Documentum Java Method Server service and your methods will be able to find your BOF classes without a problem.