I’ve decided to update my CV to reflect the time I’ve spent as Director of Vibey Subscriptions, nearly three months officially, but around six months of development. We’re nearly ready for a beta prototype, so watch this space!

My latest CV is available to download here, as well as an expansive section on my project work so far in more-depth. Please get in touch if you are interested in working with me on short-term contract or fixed-fee web development.

This post is about running the XPay client provided by SecureTrading for on-line e-commerce payment processing, but it might also be useful for anyone trying to run a java application on a Debian server, particularly if they require it to be 32-bit compatible, such as running a JRE 1.4.2, or to start-up on boot.

SecureTrading’s payment processing solution provides a Java application responsible for all the encryption and secure communication with their payment gateways, leaving the application developer only responsible for forming an XML document and transmitting it on an unsecured, local socket. I have recently completed an integration using Ruby on Rails, and things were going too smoothly; something had to be problematic!

And it was this: I was running Debian Etch on a 64-bit server, and the XPay client requires Java runtime 1.4.2, which is no longer supported by Sun and only has a 32-bit linux version (unless you’re running Intel). I thought I was stuck: SecureTrading even offered to refund me at one point. I was certain there had to be solution other than getting hold of another 32-bit box, and it was, thanks to the excellent Debian o/s.

Some boffin has packaged the libraries necessary to run 32-bit apps in the ia32-libs package, so that older 32-bit applications can run alongside up-to-date 64-bit ones. It is installed in one command:
apt-get install ia32-libs
I could then download and run the binary installer for the Java runtime environment. I could then follow the instructions to setup the client certificate in the keystore and run xpay.
/usr/local/java/j2re1.4.2_19/bin/keytool -import -alias xpay -file /var/whereever/xpay/securetradingxpay.cer \
-keystore /usr/local/java/j2re1.4.2_19/lib/security/cacerts
This leaves the task of having XPay run at startup, as an init.d script. Typically, Java doesn’t play nice with init.d scripts, but I managed to get it running with Debian’s start-stop-daemon script. Starting from the /etc/init.d/skeleton file, I trimmed most of it away to end up with:
#! /bin/sh
# Author: Dan Garland <dan@dangarland.co.uk>
# Do NOT “set -e”
# PATH should only include /usr/* if it runs after the mountnfs.sh script
JAVA_HOME=/usr/local/java/j2re1.4.2_19
CLASSPATH=/var/whereever/xpay/XPay.jar
PATH=$JAVA_HOME/bin:/sbin:/usr/sbin:/bin:/usr/bin
DESC=”Xpay Client”
NAME=XPay
DAEMON=$JAVA_HOME/bin/java
DAEMON_ARGS=”-classpath $CLASSPATH -Djava.security.manager -Djava.security.policy=/var/whereever/xpay/xpaypolicy XPay ”
PIDFILE=/var/run/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME

# Read configuration variable file if it is present
&& . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
. /lib/init/vars.sh

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

#
# Function that starts the daemon/service
#
do_start()
{
  start-stop-daemon –start –background -p $PIDFILE -m –exec $DAEMON — $DAEMON_ARGS
  echo “$NAME started…”
}

#
# Function that stops the daemon/service
#
do_stop()
{
  start-stop-daemon –stop -p $PIDFILE
  echo “$NAME stopped…”
}

#
# Function that sends a SIGHUP to the daemon/service
#
do_reload() {
        #
        # If the daemon can reload its configuration without
        # restarting (for example, when it is sent a SIGHUP),
        # then implement that here.
        #
        start-stop-daemon –stop –signal 1 –quiet –pidfile $PIDFILE –name $NAME
        return 0
}

case “$1″ in
  start)
        && log_daemon_msg “Starting $DESC” “$NAME”
        do_start
        case “$?” in
                0|1) && log_end_msg 0 ;;
                2) && log_end_msg 1 ;;
        esac
        ;;
  stop)
        && log_daemon_msg “Stopping $DESC” “$NAME”
        do_stop
        case “$?” in
                0|1) && log_end_msg 0 ;;
                2) && log_end_msg 1 ;;
        esac
        ;;
  #reload|force-reload)
        #
        # If do_reload() is not implemented then leave this commented out
        # and leave ‘force-reload’ as an alias for ‘restart’.
        #
        #log_daemon_msg “Reloading $DESC” “$NAME”
        #do_reload
        #log_end_msg $?
        #;;
  restart|force-reload)
        #
        # If the “reload” option is implemented then remove the
        # ‘force-reload’ alias
        #
        log_daemon_msg “Restarting $DESC” “$NAME”
        do_stop
        case “$?” in
          0|1)
                do_start
                case “$?” in
                        0) log_end_msg 0 ;;
                        1) log_end_msg 1 ;; # Old process is still running
                        *) log_end_msg 1 ;; # Failed to start
                esac
                ;;
          *)
                # Failed to stop
                log_end_msg 1
                ;;
        esac
        ;;
  *)
        #echo “Usage: $SCRIPTNAME {start|stop|restart|reload|force-reload}” >&2
        echo “Usage: $SCRIPTNAME {start|stop|restart|force-reload}” >&2
        exit 3
        ;;
esac

:
This script then runs XPay on boot. Make sure that the paths to the jar and the policy files are correct, and that the policy file has the correct path to the Java 1.4.2 installation directory.

I’m almost through ironing out the glitches caused by upgrading a rails 2.0.2 application to 2.2.2. Between the snippets of documentation scattered all over the web, I’ve muddled through a process that has taken a couple of days and been one of the trickiest framework upgrades I’ve had to make. For a long time, Rails kept me under the illusion that things were as easy as ‘rake makeeverythingwork’, but I think its true to say that the further I am into a rails project the less helpful the framework becomes.

I migrated two systems in parallel, my development and production environments, running xubuntu and debian etch respectively.

The first problem, as always is the case with ruby, is the documentation. In one sense, I quite like the anarchy of a completely disorganised documentation system cobbed together only by a decent search engine, but I must say that with this rails upgrade I felt very much on my own in terms of help and support, having to glean tips and derive solutions from several blogs, wikis and rdocs.

The next wall I ran into was related to the rubygem system. Far from the ‘packaging bliss’ I was sold on initially, the source index file is now so large that it completely eats the system memory and swap on my old development laptop, taking an extremely long time to complete. I learned the –no-update-sources option for gem installs, which avoids lengthly index updates. Eventually, I used gems to update rails:
gem update rails
There may have been some more commands in there. On my ubuntu laptop, I found that once I had a copy of rails 2.2.2 that everything broke, asking for a 1.3.1 version of rubygems. Using the ordinary method gem update –system didn’t work; claiming that there was nothing to update. Instead, I downloaded the gem from http://www.rubygems.org/ and installed it myself:
sudo gem install –no-update-sources –local rubygems-update-1.3.1.gem
sudo update_rubygems
Then I replaced the missing mysql adapter. Rails 2.2.2 dropped the mysql adapter from the framework, meaning that I have to re-install it to keep my app running. I will note here that the functionality that sold me on rails the first time I saw it has now been removed by default; as though rails introduced a quick method of making web-based views on mysql databases to catch peoples attention, and now they’re slowing leading them away to some other technological viewpoint. Anyway, to fix on linux I needed the mysql client development headers, found in the libmysqlclient15-dev package:
sudo apt-get install libmysqlclient15-dev
sudo gem install mysql
I was ready to run my unit and functional tests, to see what broke. In short, my application had problems with deprecated features and third-party plugins:

• In places, my application used request.relative_url_root to build URLs to resources relative to the public folder (I didn’t find a decent way of doing this without calling this method, I’d like to have something similar to image_tag). Anyway, the method was deprecated, replaced with ActionController::Base.relative_url_root. The new method returns nil if the application is deployed in the root of the domain (no context), which broke some calls which were building URL strings, so I created my own helper method to retrieve the context and changed all calls to it.
• The country_select helper has been removed. There is a replacement plugin available at http://github.com/rails/country_select/tree/master, but I found that it doesn’t work with rails 2.2.2. To avoid ‘wrong number of arguments’ errors, the following tweak is needed on line #7 of country_select.rb in the vendor/plugins/country_select/lib folder:
  InstanceTag.new(object, method, self, nil, options.delete(:object)).to_country_select_tag(priority_countries, options, html_options)
  InstanceTag.new(object, method, self, options.delete(:object)).to_country_select_tag(priority_countries, options, html_options)
• The acts_as_commentable, acts_as_voteable and acts_as_rateable plugins all broke, giving ‘Unitialized constant’ errors. This is fixed by tweaking the init.rb file for each plugin to ensure the plugin library files are loaded correctly:vendor/plugins/acts_as_commentable/init.rb:
  require File.dirname(__FILE__) + ‘/../acts_as_voteable/lib/acts_as_voteable’
  require File.dirname(__FILE__) + ‘/../acts_as_voteable/lib/vote.rb’
  ActiveRecord::Base.send(:include, Juixe::Acts::Voteable)

  require File.dirname(__FILE__) + ‘/lib/acts_as_commentable’
  require File.dirname(__FILE__) + ‘/lib/comment’
  ActiveRecord::Base.send(:include, Juixe::Acts::Commentable)
  vendor/plugins/acts_as_rateable/init.rb:
  require File.dirname(__FILE__) + ‘/lib/acts_as_rateable’
  require File.dirname(__FILE__) + ‘/lib/rating’
  ActiveRecord::Base.send(:include, Juixe::Acts::Rateable)
  vendor/plugins/acts_as_voteable/init.rb:
  require File.dirname(__FILE__) + ‘/lib/acts_as_voteable’
  require File.dirname(__FILE__) + ‘/lib/vote.rb’
  ActiveRecord::Base.send(:include, Juixe::Acts::Voteable)

• Unobtrusive Date Picker became obtrusive, requiring a complete removal from my application and re-install from http://github.com/thincloud/unobtrusive_date_picker/tree/master. Make sure the version you download has the correct copy of 12_hour_time.rb, I found that the one installed via git was the old version.

Hence I finally could run the application on the rails 2.2.2 framework. The debugging continues….