An Architect's View

CFML, Clojure, Software Design, Frameworks and more...

An Architect's View

Upgrading Railo 3 to Railo 4

October 23, 2013 · 4 Comments

At World Singles, we're just going thru the process of upgrading from Railo 3 to Railo 4 (specifically from 3.3.4 to 4.1.1) and I thought I'd jot down a quick blog post about it. First off, I should explain that we use the WAR install on a vanilla Tomcat install, and mod_proxy_ajp to connect Apache to Tomcat. See my Railo for Dummies blog post from 2009 about setting up that sort of environment for background. We have three web contexts (web applications), each running their own configured WAR install of Railo, so we can package each web application up easily and move it around, including the Railo runtime. We can also upgrade each web application separately.

We'd already upgraded from Java 6 to Java 7 (download and unpack the JDK from Oracle into a new folder, update the symlink for the default java executable), and from Tomcat 6 to Tomcat 7 (download and unpack the Tomcat archive from Apache into a new folder, update the symlink for the current version, copy and context.xml from the old to the new - we'd customized those - and then add <Host..> entries to server.xml as necessary). Piece of cake so far.***

I expected the Railo upgrade to be more work than Tomcat. I was wrong. A pleasant surprise! I downloaded the new Railo 4.1.1 WAR file and unpacked it into a temporary folder (using jar xf /path/to/railo- Then I copied the WEB-INF folder over my existing Railo installations:

tar cf - WEB-INF | ( cd /path/to/application/webroot; tar xf - )

That's just my go to method for non-destructively copying a whole directory tree on top of an existing set of files. The only file that needed customization was web.xml in one web application context where we had some SES URL patterns that matched subfolders. That was just a matter of adding three <url-pattern> lines to the <servlet-mapping> section for the CFMLServlet. That's all it took: download, unpack, copy (and a small edit). Started up Tomcat and Railo happily deployed itself into each web application context, without overwriting any of my previous Railo 3.3.4 settings in the three admins. Nice!

Any code changes? Yes, just two: ColdBox has a MessageBox plugin that uses isEmpty() which is now a built-in function - changing the two unqualified calls to this.isEmpty() solved that - and a couple of strange places where I'd accidentally used float and int as function return types in cfscript - this worked in Railo 3 as if I'd written numeric but in Railo 4 it was type checked as a Java primitive type (interesting in itself!) so I just changed those to numeric and everything else just worked!

***Piece of cake except for Braintree which is one of our payment providers. We were using an older version of their library and once we moved to Java 7, the security certificate processing was more strict and calls to their sandbox (not their production system) failed. Updating to the latest Braintree JAR on Maven Central fixed that.

Tags: coldbox · coldfusion · railo

4 responses so far ↓

  • 1 Sean Daniels // Oct 23, 2013 at 6:02 PM

    Nice. I believe the latest ColdBox addresses the isEmpty issue (3.7? Or it might only be fixed in the dev branch).

    Glad to hear it was smooth though.
  • 2 Sean Corfield // Oct 23, 2013 at 9:04 PM

    Good to know. We're stuck on ColdBox 3.0 M3 - incompatibilities between milestones stopped us upgrading years ago and since then we've been planning to migrate off it (due to thread safety bugs in the code and the complexity of the framework just generally getting in our way).
  • 3 Andy // Oct 23, 2013 at 10:44 PM

    Could you comment on the thread safety bugs in the Coldbox code that you are referring to? We use CB across a wide range of sites without issue. Where/what type of things should we be looking for here?

  • 4 Sean Corfield // Oct 24, 2013 at 7:37 PM

    @Andy, we ran into several in the logging stuff (which we've moved off anyway) and several in the flash scope inflation logic. I checked both 3.1 (and 3.3 I think) as I found bugs there, and despite the rewritten flash scope handling in latter versions, there are still thread safety bugs in the code. Early on I reported a lot of bugs we found to Luis but it got to a point where his response was just "Upgrade to the latest version and see if it's fixed" so I just stopped reporting bugs.

    We ran into bugs using ColdSpring with ColdBox and had to stop relying on ColdBox's autowiring. We ran into initialization bugs with the plugin extension system and had to do some pretty unpleasant hackery to work around. I'd hack to go through Git history to see what other problems we ran into...

Leave a Comment

Leave this field empty