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.

I wonder if they send the error report or not?

Anyway, the fix was mildly traumatic since we had to have a new hardware node built with the underlying file system formatted with a 2048 block size then moving all 5 VEs to the new system. But it went surprisingly well due in large part to the flexibility of using virtual environments.

Regardless, I wanted to note the block size available for the Ext3 file system and it’s associated limitations for myself and posterity:

However, there have been some kernel security updates recently release and when I tried to install the updates, I got 404 errors from all the sources. I’m not sure what the issue was and Google wasn’t much help either so I thought maybe just upgrading would be a good idea. Since my system was so far back rev, I decided I’d better upgrade to the next release. I found an article that two methods. I used the second which I’ll describe here since it was so simple:

1. Backup then edit the file /etc/apt/sources.list, replacing all instances of “edgy” with “feisty”.
2. Update the source listings with this command: sudo apt-get update
3. Do the upgrade: sudo apt-get dist-upgrade
4. Check it with:
   1. sudo apt-get -f install
   2. sudo dpkg --configure -a
5. Reboot: sudo reboot
6. Make sure it worked: cat /etc/issue

First thing I noticed was that hey, the upgrade just worked! And done in under 30 minutes. The only hitch was Tomcat didn’t start so the upgrade process stopped so I could deal with it. It was complaining about the JAVA_HOME environmental variable not being set. I uninstalled it then ran “sudo dpkg –configure -a” from the command line and it finished up.

The second thing I noticed was that my IMAP service was faster (I use Outlook which typically sucks at IMAP but there seems to have been some improvements on the server side in that regard).

Everything else appears to work fine too.

Next step: continue the upgrades until I get to Hardy Heron. But I’ll let this one “settle” for a while before I do that.

I found a tutorial by searching for my camera model plus HDR. This tutorial used Photoshop. I followed the instructions but really couldn’t get the effects that I had seen. I love Photoshop but it is a powerful generalized tool which means in a lot of cases going from idea to finished product can be difficult, time consuming and frustrating. (I found a better tutorial for Photoshop here, but I will still have to practice to be able to get the same results I get with less effort from Photomatix.)

Anyway, I was aware of some other tools that create HDR images so I let my frustration drive me to try Photomatix. Photomatix provides credence to the notion that purpose-built tools are many time superior to more powerful and generalized tools. Not only did it create the type of images that I have seen on Flickr and other places on the Internet but it is faster too. Here are some test images that I took and processed today:

[Show as slideshow]

(Note that I put in the two bird blind pictures as a comparison to those in my previous article, which were created with Photoshop.)

Anyway, the technique is reasonably straight forward with current technology and Photomatix. I have a Canon Rebel XTi which has an automatic bracketing feature that my friend Chris Masters introduced me to yesterday. So I configured the camera to automatically set the exposure to -2, 0 and +2. It requires a tripod so don’t forget it if you plan to try this out.

I’m going to continue to experiment with this technique to refine my understanding of it but wow…it’s just amazing what can be done with digital photography even for someone getting started with it.