URL Rewriting is fun! Well, that may be a bit of an overstatement (to say the least), but it does describe where I am with my deployment of Railo to the Aptana Cloud.

This is what I love about the web development industry. As soon as you step away from a project, something new comes along to eff with you. I had to take a few days off this fun project to actually do some billable work (my dogs really, really want me to have enough money to buy them lots of treats). When I came back, what do I find? That Railo 3.1, the long-awaited, truly open-source version of the Railo CFML engine was released into the wild.

Yeah and ugh! Yeah because I've been waiting to get my hands on this version since last summer. Ugh because I finally decided to give up on waiting and deploy Railo 3.0 to this Cloud.

Of course, this isn't really a big deal. This morning, I simply redeployed my railo.war file to the Cloud. The deployment process cleared out the previous webroot folder and deployd the new WAR file. The only bad part is that I didn't realize that this would wipe out my CFML files and other assets. If I took a little extra time and read the bloody Tomcat documentation, I'd probably have avoided this :). No biggie, nothing more than uploading via SFTP again.

Railo 3.1 is now deployed and operational on my site in the Cloud. Now, as with before, it's back to the URL Rewriting in order to get Tomcat to respond as we wish with SES-style URLs.

In my previous post on Railo and Aptana Cloud, I mentioned learning of a tool, called UrlRewriteFilter, for Java servers (i.e., Tomcat).

Over the past couple of days, and with the help of others, I began to get a set of rewrite rules in place. Some of the rules I've used (thus far) to get ColdBox and Mango Blog rolling follow.




A quick overview of the presented XML elements:
The rule element defines a URL rule -- duh :)! Each rule element must contain at least one from element and one to element. The from element is the requested URL as is. An example would be the URL you look at in your browser's address bar. It is to this element that we are applying a regular expression (the value of the from element). If our regular expression/text in the from element matches the incoming URL, the user is redirected to the value of the to element.

The first rule (above) ensures Railo (the CFMLServlet) will not process any requests for images or the other specified doc types. In this, and the other two rules listed above, the value of our to element is a dash ( - ). This tells the UrlRewriteFilter to not make any substitutions or otherwise with the request and 'go on like nothing happened.'

The second rule ensures we do not redirect requests for special applications, such as ColdFusion web administration, from being forwarded or redirected to our ColdBox application (based on the rules below.

The third rule has the same end result as the second but is more focused on remoting calls.



The two rules listed above handle all basic URL types that will come in with a very basic ColdBox application. The first of the two rules above will match any URL with the following format:

If such a URL was requested on our application, our expression (the value of the from element) will match (in order) pages, view, 3 and store them in the variables $1, $2, $3 respectively.

The next and final step in this rule is to forward the request to a specific URL. In our case it is the default file (index.cfm) for the ColdBox application. We then build the appropriate URL query string onto the file we're calling: ?event=$1.$2&id=$3

The result is a behind-the-scenes request for the following URL:

We've now 'decoded' our URL (www.mysite.com/pages/view/3) and instructed our ColdBox application to run the pages.view event and supplies that event with a variable id that has a value of 3. On a real site, this would most likely get a page from a database that has an identification value of 3 and then present that content to the viewer in the browser.

Two important notes, first, if you want the UrlRewriteFilter to stop trying to match rules on a given match, you need to set the last attribute of the to tag to true. This attribute's default value is false. I think this is important to know as you test your filters.

Second, when you are writing a value inside an XML element, you must escape the ampersand (&) as I did above. Your rule will not parse otherwise (and your XML will be invalid).

The second rule above does the same as the first but does not look for the third parameter.

This is a basic overview of some UrlRewriteFilter rules I put in place. Please note I am not offering these as the best way to use the UrlRewriteFilter. I'm just getting started and am posting this in the hopes it will help some other newbie. If anyone reading this has a suggestion or resource, please let me know!

This post, obviously, doesn't cover installation and usage of the filter itself. Be sure to check the project site for more details.


Aaron Greenlee
Helpful post. Thanks for sharing.

I am using ColdBox's SES Interceptor as well; however, I only applied a single rule after excluding unwanted requests: ^/(.*)$

Now, ColdBox's routes file can be used to manage all incoming routes. If an unknown route is called, I resolve it within ColdBox and send the HTTP 404 code while displaying results that best matched their url.