ColdFusion on Aptana Cloud with Railo 3.0; Part II

Okay, I'm freaking giddy this morning. I was finally able to install and configure Railo 3.0, an open-source CFML engine, on my development machine (Mac OS X 10.5.x).

While I already have Adobe's ColdFusion 8 (CF8) server software installed and configured on my system, I've been wanting to 'switch' to Railo since last year for a few of reasons. First, CF8 is a bit of a resource hog. It consumes between 375 and 600 MB of RAM when running. That's a lot, even with 3 GB of RAM on my machine, because I'm typically running a ton of programs and other server software. Railo, on the other hand, consumes between 200 and 300 MB. Big difference.

Second, Railo is open-source and, thereby, free. My goal, later next month, is to install it on an Aptana Cloud site utilizing it's newly released Java server options (Tomcat is the Java engine they chose) on their cloud. Once installed, I can then run a ColdFusion site on the Cloud!

Third, and this is based more on what I've read than know, Railo is purported to be a far faster engine than CF8. Not sure if that's true but I look forward to running some benchmark tests and such.

Back to the install, I've tried a few times over the past 4-6 months to install and configure Railo to work with my Apache installation. Never got it working right. I could install and run Railo off a port other than the default (80) but, as I've mentioned before, I freaking hate that.

Mercifully, Luis Majano, the creator of ColdBox, which is a kick-ass CFML framework that's taking the CF community by storm (not to oversell it or anything :), wrote up an awesome post on exactly how to get Railo running off Apache in Mac OS X.

One potential gotcha for us Mac folks, Luis uses the default Apache installation that comes with Mac OS X. Nothing wrong with that, of course, but when you get to the commands to make and make install the mod_caucho.so connector, you might have to do some manual tweaks there. Email me if you run into such a problem and I can tell you how I got around it.

Finally, and since I suck at writing Launch Daemons, I altered my Automator application that started the Jaxer server after install to also run an AppleScript I wrote to start Railo as well.

I know this is über-geeky but I'm so excited to have Railo running off my standard Apache install. It rocks!

In my previous post regarding Railo and Aptana Cloud, I left off dealing with SES-style URLs not being processed by Tomcat. After much research (Google, forum threads, etc.), I learned this is an issue with Tomcat itself...sort of.

On Aptana Cloud, Apache's role, as I understand it, was simply to pass all requests to Tomcat, which is the HTTP server on the site. This is a smart design since Tomcat for a single site/application will perform better than Tomcat connected to Apache via a module, such as mod_jk.

Well, the downside is that Tomcat cannot properly parse SES URLs, more specifically, it has an issue with some wildcard characters in it's web configuration file that we'd need to use for SES URLs.

I should clarify something. Tomcat parses URLs correctly, following the URL specification. However, many dynamic web applications use URL in a different way. Specifically, many of our dynamic applications use the URL as a set of instructions to the application and not as a reference to an actual resource (file or directory) on the server.

For example, in a ColdBox application, uses a URL such as the following:
http://www.mysite.com/pages/view/3

There's not actually a directory on the server named 3 that resides in a directory called view that resides in a directory called pages. This URL is merely an instruction to the ColdBox framework. It's saying (in essence): find the pages controller, run the view method and pass the view method the value 3. In English, it's a (very) basic way of saying show me a page in the database that has an ID of 3.

Tomcat, however, sees the URL above indicating that the user wants (is requesting) an actual resource on the server. It will try to find the folder 3 inside a folder called view inside one called pages. Attempting to access a similar URL to the one above on my Cloud site results in a 404 error (resource/file not found).

The 'problem' is that when you set up the servlet mappings in Tomcat's web.xml file for Railo (Railo is but a servlet that Tomcat tells to handle any and all CF-related requests) Tomcat does not hand off URLs such as these to Railo for processing, instead processing them itself.

In the Tomcat web.xml file, there is a servlet mapping element (can be many of them, actually), each with a url pattern element that instructs Tomcat to hand off certain URLs to a particular servlet. I'm saving the detailed code for my next post but here's a sample:

  CFMLServlet
      *.cfm

This instruction tells Tomcat to hand off any URL with .cfm at the end to Railo, which is the CFMLServlet. It works great when you actually use CFM pages in your URL (www.mysite.com/page.cfm or www.mysite.com/page.cfm?id=3).

If you don't use CFM files in your URL as the above, you're hosed :). Well, kind of.

Ideally, and what some other Java-based servers allow (jboss is an example), is that we'd tell Tomcat to pass any URLs matching *.cfm/* off to Railo.

  CFMLServlet
      *.cfm/*

The added /* would ensure that URLs such as the one above get passed to Railo for processing (and are thus not processed by Tomcat). Unfortunately (for me, anyway), Tomcat doesn't do this.

The solution (for now) is to create some URL rewrite rules, such as is done with IIS or Apache to create SES URLs on those servers. Because Aptana Cloud is setup such that Tomcat handles the HTTP requests, using Apache's mod_rewrite (a powerful URL rewriting module) is not possible.

A little Googling turned up a utility called UrlRewriteFilter. This, in essence, was created to replace many of the features of Apache's mod_rewrite. It's not a duplication of mod_rewrite and some key elements are missing. However, it does let us get URL rewriting working on Tomcat.

I'm still working on my rewrite rules and trying to optimize them, work out kinks, and look for genuinely good alternatives. My next post will cover those rules.