Want more information about what an .msi is doing on your system or what caused a generic and completely useless error message to pop up? Run the following command substituting the path to your .msi from the command line and the output file will contain verbose logs.

Jenkins (or Hudson if you work for Oracle) is a great, simple and steady continuous integration and build server. One of its greatest features is that despite being packaged as a standard .war ready to be dropped into your JEE web container of choice … it also contains an embedded web container that makes the .war everything you need in most situations. Simply run

java -jar jenkins.war

and up starts Jenkins on port 8080 in all of its glory. All of Jenkins’ configuration files, plugins, and working directories go under <USER_HOME>/.jenkins by default. Perfect.

Except if you want to run multiple instances on the same machine. We are going to get a config folder collision. It turns out this is a piece of cake, but the docs are hard to find. Jenkins will use a JENKINS_HOME path environement variable for its configuration files if one is set so a simple change means we can run Jenkins out of any directory we desire:

java -DJENKINS_HOME=/path/to/configs -jar jenkins.war

What about the port you say? Winston, the embedded web container used, has a simple property for this too:

Since we watched the logs most often using the tail command, the quick and dirty solution was to have tail output lines containing WARN/ERROR/SEVERE in different colors that would stand out as the scrolled past. The bash/perl script below is the fruit of my hacking. Suggestions for improvements welcome.

Be careful when doing cross-browser AJAX because IE and Firefox handle client-side caching very differently. Last week I ran into a situation where a new in our app was misbehaving in IE but working perfectly in Firefox. The culprit ended up being IE’s caching of our AJAX calls to kick off jobs and poll to see if they were finished. IE was caching all AJAX calls by default which reaked havok on our user’s workflow. Firefox sends an “If-Modified-Since” header on subsequent GET requests giving the server the chance to determine if a resource cache can be used or not. IE 8 doesn’t.

To make matters worse, I had actually added some anti-caching logic into our code … but had accidentally moved the code to a point where it wasn’t being invoked (oops!).

The solution ended up being adding an extra parameter to each AJAX request populated with the current timestamp value in miliseconds

var url = "http://our-app/action?no_cache=" + new Date().getTime();

JQuery’s AJAX utilities methods do this by default (so long as the cache option isn’t set to false) but it doesn’t look like Prototype.js does by default. From Prototype’s AJAX documentation:

You can use parameters with both GET and POST requests. Keep in mind, however, that GET requests to your application should never cause data to be changed. Also, browsers are less likely to cache a response to a POST request, but more likely to do so with GET.

Together, IE stopped caching our requests and everything went back to normal.