Deploying ChiliProject on Tomcat

We have been using Redmine as our project management tool of choice at work for about a year and half. We use it primarily to manage our Pentaho and data warehouse implementation, along with some smaller initiatives. It meets our needs quite well by allowing us to host multiple projects (unlike Trac) with different needs on the same deployment. I love how flexible and easy it is to configure, however, I also like to keep my eyes open for potential alternatives. The last time I upgraded our Redmine installation, I decided to deploy Redmine on our Tomcat environment in an attempt to avoid having to maintain a apache+passenger install purely for Redmine (most of the apps we host are java based, so my Tomcat skills are much more polished than my apache+passenger skills).

I recently discovered ChiliProject, which is a fork of the Redmine project, and thought I’d take it for a spin. While Redmine project is very stable, it is a little slow to implement new functionality. That appears to be the primary reason for the ChiliProject fork. After browsing through their documentation and doing some google digging, I noticed that there is little to no information on how to deploy ChiliProject to Tomcat. I thought I’d take the time to try to fill the gap a little. It is my hope that this guide will serve as a reference for those of you who are working in primarily Tomcat-oriented shops, but are interested in test driving a high quality ruby-based app without having to setup the required apache+passenger (or nginx+passenger) infrastructure.

This guide assumes that you already have the following knowledge:

  • Basic shell skills
  • How to setup and secure a mysql server
  • How to setup and secure a tomcat server

I developed this guide on a Fedora 16 installation at home, but I am confident that it will work just as well with CentOS, Scientific Linux, or any other RHEL derivative. You can also swap the package names for your favorite non-RedHat Linux distribution.

Required software packages:

  • tomcat6
  • java-1.6.0-openjdk
  • mysql-server

Recommended software packages:

  • tomcat6-admin-webapps
  • tomcat6-webapps

Files to download:

Installing JRuby

A JRuby installation is only needed to provide an initial environment for configuring and testing
the web application. Once we deploy the chiliproject war to Tomcat, our JRuby installation will
only be needed for subsequent upgrades or installing and testing plugins. Consequently, I don’t
bother installing any official JRuby packages. Here is my barebones installation process:

  1. If you don’t already have a bin directory in your home directory, create one:
    cd ~/.
    mkdir bin
  2. Extract the JRuby tarball to your newly created bin directory:
    cd bin
    tar -xzf ~/Downloads/jruby-bin-
  3. Add the JRuby bin directory to your path:
    cd jruby-
    export PATH=${PATH}:${PWD}

Initial ChiliProject install

  1. Go back to your bin directory and extract the chiliproject tarball:
    cd ~/bin/
    tar -xzf ~/Downloads/chiliproject-2.6.0.tar.gz
  2. chiliproject uses bundler to manage the gems it depends on, so let’s install bundler:
    cd ~/bin/chiliproject-2.6.0
    jruby -S gem install -r bundler
  3. The stock Gemfile assumes you’re going to run this on a native ruby installation. This causes a problem when it tries to install rmagick. Edit the Gemfile to replace rmagick with rmagick4j. Edit the following lines:
    group :rmagick do
      gem “rmagick”, “>= 1.15.17”
    to match:
    group :rmagick4j do
      gem “rmagick4j”, “>= 0.3.7”
  4. Install the required gems with bundler:
    jruby -S bundle install –without test development
  5. Create the chiliproject database:
    mysql -u root -h localhost -p
    create database chiliproject character set utf8;
    create user ‘chiliproject’@’localhost’ identified by ‘password’;
    grant all privileges on chiliproject.* to ‘chiliproject’@’localhost’;
  6. Copy the database.yml.example to database.yml
    cd ~/bin/chiliproject-2.6.0/config
    cp database.yml.example database.yml
  7. Edit the production section of the database.yml file with your favorite editor. The key change for a tomcat deployment is to make sure that the adapter property is set to jdbcmysql and not mysql. Here’s a copy of mine:
      adapter: jdbcmysql
      database: chiliproject
      host: localhost
      username: chiliproject
      password: password
      encoding: utf8
  8. Copy the configuration.yml.example to configuration.yml
    cp configuration.yml.example configuration.yml
  9. Generate the session store:
    jruby -S bundle exec rake generate_session_store
  10. Start mysql (as root):
    service mysqld start
  11. Define the application’s mysql objects using rake db:migrate:
    RAILS_ENV=production jruby -S bundle exec rake db:migrate
  12. Load the default installation data:
    RAILS_ENV=production jruby -S bundle exec rake redmine:load_default_data
  13. Test the initial installation on the rails webrick server before moving forward:
    cd ~/bin/chiliproject-2.6.0
    RAILS_ENV=production jruby -S script/server -e production

Additional steps for final tomcat deployment

  1. Install warbler:
    jruby -S gem install -r warbler
  2. Create a warbler configuration:
    jruby -S warble config
  3. Edit the warbler configuration
    cd ~/bin/chiliproject-2.6.0
    vim config/warble.rb
  4. Uncomment and change config.dirs to match the following:
    config.dirs = %w(app config lib log vendor tmp extra files lang)
  5. Uncomment and change config.gems to match the following:
    config.gems += [“activerecord-jdbcmysql-adapter”, “jruby-openssl”, “i18n”, “rack”]
  6. Uncomment and change config.jar_name to match the following:
    config.jar_name = “chili”
  7. Uncomment the runtimes configuration to match the following:
    config.webxml.jruby.max.runtimes = 4
  8. Install a specific version of the jruby-rack library:
    jruby -S gem install -r -v=1.0.9 jruby-rack
    jruby -S gem uninstall jruby-rack -v=1.1.3
    Note: I have had issues with the 1.1.x jruby-rack library. After deployment, you’ll get an exception complaining about a call to raw_post. The same error does not occur when using the 1.0.x version of jruby-rack, hence the need to install an older version.
  9. Build the war file:
    cd ~/bin/chiliproject-2.6.0
    jruby -S warble
  10. Prepare a folder for deploying the webapp (as root):
    cd /var/lib/tomcat6/webapps
    mkdir chili
  11. Extract the chili.war file to the new webapp directory (as root):
    cd /var/lib/tomcat6/webapps/chili
    unzip -q <user home>/bin/chiliproject-2.6.0/chili.war
  12. Set the proper permissions on the chili webapp directory (as root):
    cd /var/lib/tomcat6/webapps
    chown -R tomcat:tomcat chili/
  13. Start tomcat (as root):
    service tomcat6 start
  14. Start a browser and test your deployment by going to the following URL:

Other notes

For reference purposes, here are the gems that I installed at the time that I wrote this article (using jruby -S gem list –local):

*** LOCAL GEMS ***

actionmailer (2.3.14)
actionpack (2.3.14)
activerecord (2.3.14)
activerecord-jdbc-adapter (1.2.1)
activerecord-jdbcmysql-adapter (1.2.1)
activerecord-jdbcpostgresql-adapter (1.2.1)
activerecord-jdbcsqlite3-adapter (1.2.1)
activeresource (2.3.14)
activesupport (2.3.14)
bouncy-castle-java (1.5.0146.1)
bundler (1.0.21)
coderay (0.9.8)
fastercsv (1.5.4)
i18n (0.4.2)
jdbc-mysql (5.1.13)
jdbc-postgres (9.0.801)
jdbc-sqlite3 (3.7.2)
jruby-jars (
jruby-openssl (0.7.4)
jruby-rack (1.0.9)
json (1.6.5 java)
net-ldap (0.2.2)
rack (1.1.3)
rails (2.3.14)
rake (, 0.8.7)
rdoc (3.12)
rmagick4j (0.3.7)
ruby-openid (2.1.8)
rubytree (0.5.3)
rubyzip (0.9.5)
sources (0.0.1)
warbler (1.3.2)


02/13/12 Update:

I have tested my steps against the new 3.0 release of Chiliproject along with jruby 1.6.6 and it works just fine. You’ll still need to make sure you use a downgraded version of jruby-rack. It appears the latest 1.0.x release is 1.0.10 as per

Gnome 3 Extensions for Traditionalists

Shortly after Fedora 15 was GA’d, I decided to take the plunge and give Gnome 3 a try. Gnome 3 is, in my humble opinion, such a drastic change from the traditional desktop environment that I have had a very difficult time adjusting to how different it is. Call me old fashioned, but I like a few icons on my desktop, a fixed dock for shortcuts to my favorite applications, and a minimize button. My first Gnome 3 experience on my laptop, which I use for testing new releases, was a failure. Therefore, when it came time to upgrade my main desktop at work, I chose to once again attempt a conversion to KDE 4.

I am now 3 weeks into that experiment and I am ready to pull my hair out. I have primarily been a Gnome user during my 8+ years as a Linux user, mostly because Gnome has always had just enough to satisfy my desktop needs. KDE has always felt bloated and I’m not a fan of its visual styling. With that said, I still take new KDE releases for a spin to satisfy my curiosity. Each test drive has always ended the same way with me becoming utterly frustrated with some aspect of KDE.

After a valuable discussion with a fellow Fedora user at work, I decided to take another look at Gnome 3 this past weekend. He suggested that I dig into some of the extensions that have been released which can help make Gnome 3 feel more like Gnome 2. What follows are my notes on how to make Gnome 3 more palatable. A tangential goal was to rely primarily on packages that are already available in either the main Fedora repos or the rpmfusion repos.

Install a couple packages:

  1. yum install gnome-tweak-tool
  2. yum install gnome-shell-extension-workspacesmenu
  3. yum install gnome-shell-extension-dock
  4. yum install gnome-shell-extensions-places-menu
  5. yum install gnome-shell-extensions-alternative-status-menu
  6. yum install gnome-shell-extensions-drive-menu

Use the gnome-tweak-tool to:

  1. Under File Manager: set “Have file manager handle the desktop” to On
  2. Under File Manager: set “Computer icon visible on desktop” to On
  3. Under File Manager: set “Home icon visible on desktop” to On
  4. Under File Manager: set “Trash icon visible on desktop” to On
  5. Under Interface: set “Icon Theme” to Fedora
  6. Under Shell: set “Arrangement of buttons on the titlebar” to All

The above two sections were accomplished without any unsustainable changes to json config files or downloading and installing extensions from source. However, a few pieces were missing: fixed workspaces, an Applications menu like Gnome 2 (instead of the Activities in Gnome 3), and the tried but true window list applet.

After some research, I stumbled across Ron Yorston’s collection of extensions, which are available from here: Ron was nice enough to provide both a 32 bit and 64 bit RPM for Fedora 15, which I installed with the following command:

  • yum localinstall

Rather than copying and pasting my command, I suggest you check his site for the latest version of the extensions. As Ron mentions, “The extensions hook into the very core of the GNOME shell. It’s almost inevitable that future changes to the shell will break them (though I’ll make every effort to unbreak them).”

So that’s my two cents on how to adjust Gnome 3 to my tastes. I’m actually pretty pleased with the results and if I can overcome a few other issues, I plan to use the same configuration on my workstations at home and at work. If you have anything to add, please feel free to post your thoughts in the comments.

Site Relaunch

Since I’m six days away from officially completing my masters in Computer Science, I have some extra time on my hands. I’ve decided to take the easy way out and ditch Drupal for WordPress and not write my own theme. The plan will be to focus on project management, Pentaho, linux, databases, and other random thoughts.

Here’s a rundown of what I’ve been up to:

  • My wife and I had our first child back in November
  • I’ve spent the better part of the last 5 months researching NoSQL datastores for an Independent Study
  • I’m managing a data warehouse and Pentaho implementation at work