Jeff Beard

I had occasion to install Artifactory, a Maven 2 Repository system, and Hudson, a Continuous Integration engine today and ran into some issues I wanted to note.

Both packages are Java web applications but the standard Artifactory distribution comes with Jetty in order for it to be a runnable application with a single download. We use Tomcat as our Servlet container for all our custom Java applications so I was deviating somewhat from the norm.

And even though we use Tomcat 6 from an archive downloaded from the Apache web site, I decided to  use the package that comes with CentOS 5 (x86_64) in hopes of easier maintenance since this Tomcat instance won’t be running our custom Java applications. (The Tomcat version that comes with CentOS 5 is 5.5.x.)

Anyway, I installed Hudson by dropping the WAR file into the Tomcat webapps directory and accessed it’s context with a browser. I got a 404 which indicates that the application did not start. A quick scan of the logs showed that I need to get a home directory for Hudson. So I created the folder it was trying to use and made it writable by the tomcat user then restarted the container. I tried again but got a stacktrace indicating that there was something a permissions problem of some sort. I Googled the error and found a found my way to this issue in the Hudson bug tracker. I downloaded the previous version, dropped in on top of the deployed WAR file and it Just Worked.

Next I configured the Artifactory environment according to the instructions, restarted Tomcat then dropped the Artifactory WAR file into the webapps directory. Accessing the application with my web browser resulted in a stacktrace.

The first issue I noticed was that there was an NoClassDefFoundError:

javax.xml.transform.TransformerFactoryConfigurationError : Provider org.apache.xalan.processor.TransformerFactoryImpl not found.

So I Googled the error found this bit on Nabble which told me to set TOMCAT5_SECURITY=no in my init script. They also mentioned the JVM setting “-Djava.endorsed.dirs” so I made sure that was NOT set to anything in the Tomcat startup scripts (the init script calls /usr/bin/dtomcat5) . I also took a peek in the Tomcat endorsed directory to see what was there and if it might be missing some jar files. Here I found some odd symbolic links where the files names were in brackets.  I removed them and replaced them the original file names. Then I restarted Tomcat again tested and found that it worked.

Next time, I’ll probably stick with using the downloaded Tomcat packages instead of the OS bundle. I get much more consistent results with that approach.

• Leave a comment...