Mar
7

A few days ago I worked on installing the latest version of BrowserHawk (9.0) on our production servers at work. We were upgrading from v7 to 9.0 so I was being careful to make sure the BrowserHawk specific code was addressed as well as making sure we removed code that was no longer supported. There were also some new features I wanted to employ and a few things that needed to be rewritten because of the way BrowserHawk itself had been updated.

Getting everything installed and tested on our testing server was relatively quick and painless. When it came time to push the files to production I was confident the process would go smoothly; this was not the case. Nearly 2 years ago version 7 was installed by someone other than myself. After shutting down the Web server and the appropriate cfusion server on JRun4 I remove the old files and copied the new BrowserHawk files and restarted all services. Testing some of our sites showed immediate problems. I was getting a weird error notification about the ports to test not being configured correctly. I was baffled because we weren't even testing open ports. I abandoned the rollout and pushed the old files up.

The next morning I got to looking around the JRun server and discovered someone had placed a BrowserHawk JAR file in one of the global classpaths accessible to all Java applications running through JRun. I had not removed this JAR file during deployment the previous day. Shame on me for not noticing it. However, shame on the previous developer who apparently knew very little about J2EE/JRun4 classpaths. Whomever had deployed BrowserHawk 7 had apparently not been able to get it to work because they had installed all the necessary files in every single classpath available to the cfusion instance.

By default the JVM on JRun4 searches the following classpaths:

  1. jrun_root/lib
  2. jrun_root/servers/lib
  3. servers/server_name/SERVER-INF/lib
  4. web_app/WEB-INF/lib

Depending on what I am deploying and which JRun instances need access I either load the new files into the instance-specific classpath or the server-wide classpath, but never both. By missing the JAR file deployed to jrun_root/servers/lib my instance-specific JAR was getting trumped.

So, if you work with Java in your CF development make sure you know what is installed where and why. Also, try to educate those around you (if necessary) on the application server setup. And by all means, if you are unsure how to deploy something don't start throwing JAR's everywhere until it works, ask someone who knows more than you.

Aaron West's Gravatar
About this post:

This entry was posted by Aaron West on March 7, 2006 at 1:58 PM. It was filed in the following categories: ColdFusion. It has been viewed 1190 times and has 0 comments.

0 Responses to Know Your J2EE Classpaths - BrowserHawk Upgrade