Month: June 2005

One way to tell your Documentum Java Method Server how to find your BOF objects

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:

<target name=”classpath_jar”>
    <jar destfile=”${dir.dist}/nav.jar” excludes=”*.jar” >
        <manifest>
            <attribute name=”Class-Path” value=”nav/lib/nav_server.jar nav/lib/someother.jar nav/lib/andanother.jar”/>
        </manifest>
</jar>
</target>

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.

Open source CMS articles

Two articles on the State of OS CMS.

There
are two recent articles on the state of OS CMS: “The State of Open
Source CMS” by Gregor Rothfuss in the Cutter IT Journal which you need
to subscribe to read; and “Straight from the Source: Open Source
Content Management” by John Harney in inaugural issue of Enterprise
Open Source Journal. Writing on this topic is a daunting task because
the space is so expansive and dynamic. These

By noemail@noemail.org (Seth). [Enter Content Here]

JSR 170 approved

Content Repository Standard Approved by JCP Executive Committee.
Day Software announced that the JSR 170 Content Repository for Java
Technology API has been approved by an industry expert group of the
major players in content management. JSR 170, which has been developed
under the Java Community Process (JCP) program, is designed to lessen
the risks of proprietary vendor lock-in by improving the
interoperability between content repositories and applications. This
new standard helps companies manage content across large-scale
enterprises. Day’s CTO, David Nuescheler, has lead the JSR 170
initiative by acting as the specification lead since its inception.
Apache, BEA Systems, IBM, Oracle, and SAP amongst many others all serve
as members of expert group for JSR 170. Other industry participants
include Documentum Inc., Filenet, and Vignette. http://jcp.org [Gilbane Report News]

Internal source code control revamped

I finally got our internal source code repository and build management system in place. In the old days we used Lotus Domino to store client deliverables and code. Because it wasn’t integrated with the development tools, it wasn’t kept up-to-date and wasn’t leveraged as often as it should have been. Eventually, people began relying on their own local code archive.

With the new infrastructure in place I’m hoping we’ll see a more up-to-date and more frequently utilized repository. Plus, because we are starting to see some in-house development efforts, this kind of integrated infrastructure became critical.

We’re using Subversion for source code control and TortoiseSVN/Subclipse as source code repository clients. All of those tools are available at Tigris.org.

We’re using Anthill as the build management system. Anthill runs builds for each of the projects in Subversion on a schedule and notifies us via email if any of the builds fail.

Quick lessons learned

Setting up Subversion on Windows was quick and easy. Subversion comes with Fedora Core 3 which is what we’re running on our repository and build servers but it was a bit trickier to get the server daemon working. I didn’t work on that piece so I don’t have specifics.

Getting Subclipse to work should have been easy. For most of the developers it was. For me it was a headache. I did something I shouldn’t have (not sure exactly what) and ended up making my default Eclipse workspace unusable for Subversion-managed projects. No big deal though–I just created a separate workspace directory for those projects and it’s all good.

I made liberal use of properties in my Ant scripts. This made my build scripts portable–I use the same script on my local machine as I do on the build server but with different properties files. This also makes it easy for other developers to configure the build for their preferences without altering the build script itself. There’s a really good article on Ant best practices here for more info.

Once I got my config in place, Anthill worked great. There are several things to be aware of, though. They are covered below.

Anthill

The Anthill install was a breeze. They’ve got an example project that checks code out of their CVS repository and builds it. That was handy. The install is a matter of unzipping the dist and copying a WAR file to your app server. There were a few stumbling blocks on the config for my projects, however.

First and foremost, I wish I would not have used spaces in my Eclipse project names. Anthill definitely has trouble coping with spaces. To work around this, I escaped the spaces in the SubversionRepositoryAdapter url property, like this:

svn://some-server/some-repos-path/some-repos/trunk/Some%20Project%20Name

and mapped it to a work directory that did not contain spaces, like this:

work/some-proj-name

There is still a space-related problem when Anthill tries to label my code in Subversion. I haven’t drilled into that one yet.

Second, the Anthill user interface leaves a little to be desired. One pain point is the anthill.build.ant.params. If you want to pass in an ant property and value, that’s two params. And, you have to do an update/edit for each param. If you have a lot of params it is really tedious. (The update-sends-you-back-instead-of-leaving-you-in-edit-mode problem is pervasive in Anthill. There needs to be a “Save” button and a “Close” button or something similar).

For example, suppose you have two ant properties you want to pass in and one includes a value. Something like, “-propertyfile someprops.properties -verbose”. In the Anthill config, this is three entries. Don’t try to put them in the same entry. You have to specify “-propertyfile”, click “Update” (which closes the project), and then re-open the project. You repeat those steps for “someprops.properties” and “-verbose”.

I also noticed a bug in which if you try to save clicks by deleting an existing param and adding a new one in the same step, the index used internally in the anthill props file for your project gets screwed up.

Last, although the Anthill documentation says you do not have to modify your Ant scripts to use Anthill, you actually do have to modify them if you plan on using dependency groups. Dependency groups tell Anthill how your projects rely on each other so it can build them in the correct order. For each project in a dependency group Anthill calls a target named “dependency”. That call gives you the chance to copy the JARs other projects are depending on to the right place. I already had that handled but I still needed to use dependency groups to control the build order so I ended up adding dummy “dependency” targets in all of my build scripts. I need to do some tests to make sure that dependent projects are getting built when they need to be.