What I've learned about Railo

Posted by Jason Durham | Tags: ColdFusion , Railo

Railo works on a myriad of application servers. Throughout the product lifespan, Railo has provided interoperability to at least a half-dozen or so of these. Perhaps this is why centralized documentation is scarce. The current release is now coming bundled with Resin. In my relatively small world of Microsoft, I hadn't heard of Resin. When it came time to configure it, there were certainly some growing pains of not being able to point+click at websites to configure them.

What's different with Railo

As I mentioned above, there are now 3 parts of the puzzle for developers/admins coming from my experience. Railo is the CFML engine, Resin is the middle man, and IIS (or Resin's web server) facilitates the communication with the client and server. In some cases, Resin must be aware of IIS configurations so they know how to play nice together. One example, is virtual hosts/sites. In other cases, Resin and Railo must be synced (mappings, for example). To top things off, Resin isn't very forgiving if you violate the XML schema of its resin.conf file. I have yet to find logging that would make debugging the mal-formed XML easier. However, perhaps that's another part of the documentation I haven't stumbled over.

Unlike ColdFusion 8 Developer/Standard (not sure on Enterprise), Railo is context-based. This means you can set different parameters for each application running through Railo. In order to modify an applications settings, you must access the Railo context for that application. The installer creates a start menu item for the Railo Administrator and directs you to http://localhost:8600/railo-context/admin/index.cfm. This was somewhat misleading to me. That link will only allow you to make changes to applications accessed via http://localhost/. If your development machine uses the basic http://localhost/siteFolder/ environment, you're probably fine making all changes to the link in the start menu. However, if your sites setup to route by host name, each of them will have their own context. The sites running on my development machines use a host name of dev.mydomain.com. Therefore, each application has it's own Railo administrator located at http://dev.mydomain.com/railo-context/admin/index.cfm. Be sure to create the appropriate mappings and DSNs in the correct context.

Are you Adobe ColdFusion developer considering switching to Railo?

Spend some time reading through the Resin configuration docs and wiki. Also, search the Yahoo Railo group archive. Whatever time you budget to install and configure Railo, double it.

I'm not quite ready to give any 'final thoughts' on my opinion of Railo. I installed Railo over the holiday season, which may have led to slow responses for help. During my quest for documentation/help, I found many people very happy with the support Railo provides. I was surprised (and elated) that Gert Franz offered to log into my box and save me the trouble of trying to piece together terminology that was not familiar to me. +20 points for Railo.

January 05, 2009

6 responses so far ↓

Tony Garcia - Jan 5, 2009 at 4:00 PM
With the Developer Edition of Railo, you also have a Server Administrator console in addition to the Web Administrator. So you can set DSN's, mappings, etc in the Server administrator that will apply to ALL contexts on the server, even if you're using different virtual hosts (and you can then override on a per-context basis with the Web Administrator).
For production sites, the free Community Edition has a much more limited Web Administrator so most settings have to be set for each context as you mentioned. However, the Enterprise Edition has the full-featured Server Administrator, and it is my understanding that the upcoming Open Source Version 3.1 will as well.

Jason Durham - Jan 5, 2009 at 4:04 PM
You make a good point. Some of the information I provided above may be specific to Railo 3.0 Community. :)

Tony Garcia - Jan 5, 2009 at 4:25 PM
Yeah -- I guessed that you were talking about the Community version. I'm using that for a couple of small sites and like you I had to get used to each having their own admin/settings (but that definitely also has its perks!). For local development, though, I just use the Developer edition and the Server Administrator -- mostly out of laziness for not wanting to configure some common mappings for every site.
I'm curious to see what you end up thinking about Railo. I'm very pleased with it so far and have found that claims about its speed are not exaggerated.

garryetWQ - May 15, 2009 at 2:48 AM
To my mind, Adobe needs to do something to their licensing structure. Right now it's very hard to use on Amazon EC2 and other scalable data centers. It is possible to use Amazon EC2 http://file.sh/Amazon+EC2+torrent.html to quickly scale from 1 to 10 (for example) servers when you get a sudden rush of traffic, but how do you handle the CF licenses? Right now you’d have to buy 10 licenses and let 9 of them be wasted most of the time.

James Allen - May 31, 2009 at 2:31 PM
What an awesome post!

Thank you for sharing your experience - it's been massively appreciated. I have just built my VPS today and the whole virtual sites issue was doing my head in. The whole contexual thing was the missing piece and now my IIS 6 Railo 3.1 install and moving along nicely.

I may blog about my IIS 6 experience myself to get everything I've encoutered today documented. :)

Jason - May 31, 2009 at 7:36 PM
I'm glad it helps. That's what it's here for. :)

doLearn()