Damon Gentry

This weekend, I took the first step in what I hope will be a long journey.  A good friend of mine (my son’s godfather and my carpool buddy) has been brewing his own beer for several years and I decided to give it a go.

Like writing software, making beer is easy.  Making good beer is harder and involves using better tools and using advanced techniques.  Fortunately, with an experienced brewer by my side, I’m able to skip past all the novice stuff (extracts) and go straight to an intermediate level.

I’m going to wait until my 3rd of 4th batch before I start blogging about the process, but I thought I’d share a few photos with you to show you the setup.

We made an amber ale, and apparently its tradition to give your batch of beer a name.  I’ve settled on “Galt’s Gulp”, in homage to John Galt’s Rocky Mountain hideaway, Galt’s Gulch.

Here are some photos of the setup, and the beer in the initial fermentation stage.

I finally got tired of seeing log entries for missing ‘favicon.ico’ requests.  I found a very easy fix for this.

# Rewrite rule for /favicon.ico requests

RewriteEngine On

RewriteRule .*favicon\.ico$ /favicon.ico [L]

I hit something of a milestone yesterday. My trusty old Toyota truck topped 175,000 miles. I am the original owner of this truck. It’s a 1996 Toyota Tacoma that I bought in October of 1995. I am the original owner, and it was the first new vehicle I ever purchased. There’s some minor body damage, but other than that, the truck is still in great shape.

Some web infrastructures use a content server switch to decide which server (or set of servers) in a back-end server farm will receive the request for a particular HTTP request. For example, http://your.domain.com/foo may be served by one web server, and http://your.domain.com/bar may be served by a different web server.

At my company, we employ the Cisco Content Server Switch (CSS) and the Cisco Application Control Engine (ACE) to perform this role. Actually, we use multiple server farms to handle requests (call them farm-A, and farm-B). Recently, we discovered an interesting issue regarding Flex remote object calls to our site. read more »

Just because I’m that type of guy…..

I was able to get Railo deployed under JRun (as well as ColdFusion deployed on Tomcat). I’m finding that Railo is (at a minimum) about 50% faster than CFMX (under either java container). In fact, my performance stats were pretty consistent even when switching between java containers.

However, I’m also finding that when I move an existing railo app into JRun, I’m getting errors parsing the ‘fusebox.xml.cfm’ templates, which means I’m currently limited to testing fairly simple applications. Kinda frustrating, but also very cool.

But why deploy railo under JRun? Simple: the JRun proxy connector allows me to keep all my CFML templates in an external document root. And, I can deploy multiple contexts, each with a separate document root. But with JRun at EOL, I’m not sure if there’s any real possibilities beyond the ‘cool’ factor.

Update: Sean Corfield also had the XML parsing issue with Railo on JRun. See his post for the solution.

I’ve been more and more interested in Railo lately. With big (well, at least big to me) names like Peter Bell, Sean Corfield, and Simeon Bateman adopting Railo, I can’t help but think that there is a big change coming for CFML applications.

On my MacBook Pro, I’ve currently ditched JRun/ColdFusion for Railo on Tomcat. I quickly ran into the somewhat infamous Tomcat SES issue. In short, Tomcat doesn’t quite know how to handle SES URLs. Apache has mod_rewrite, but Tomcat doesn’t ship with a built-in rewrite handler.

Sean Corfield started the discussion. But koodos to Craig Kaminsky for finding (imho) a better solution .

So, between these two blog posts, I’ve been able to run Railo 3 on Tomcat using Fusebox 5.5 with SES URLs. Hopefully, I’ll be updating my new web hosting site to use Railo and get back to using CFML for my personal site!

I firmly believe that Microsoft, Apple, and Linux vendors have figured out that user don’t want to compile software, they just want to install it. Give me a .msi, .dmg, or a .rpm file any day of the week. I’m sick and tire of: ./configure, make, make install. AARRRGGGHHH!

I’m in the process of upgrading our web infrastructure.  At my organization, we use shared development and production environments.  For the past few weeks, the new development server has been up and running side-by-side with the old development server.  However, I’m at the point where I need to shut down the old development server and require our internal users to test their sites and applications on the new development server.

I wanted to modify the Apache DocumentRoot and change it from the normal web root to a new directory with a single page informing users of the change.  I also wanted to use a custom 404 error handler to inform the user community about the change and at the same time, offer them a link to their requested page on the new development server.

I modified the Apache server to use a CFML template as the 404 error handler for the server (/error/404custom.cfm).  Now, when users request (/foo/bar.html), they see the custom 404 page that I have created.  However, using CFML variables, I was not able to determine the original file that they requested.  Dumping the CGI scope did not show (/foo/bar.html) in any of the variables present.  CGI.SCRIPT_NAME displayed the path and file of my custom 404 error page.

I found (via Google) a reference for some PHP code that was able to get the originally requested file.  The article mentioned that the web server (Apache) would create a new environment variable called ‘REDIRECT_URL’.  I used cfoutput to display CGI.REDIRECT_URL and I was able to see the originally requested template.

Apparently, this new CGI environment variable is only available if the Apache server is processing a 404 error handler.  These new variables are not described in the CF8 Livedocs.  However, there is some documentation about then in the Aapche Custom Error environment variables.

Now, when users request a page on the old development server, they are presented with a link to the same page on the new development server.

<cfscript>
myRequest = GetHTTPRequestData();
queryString = “”;
protocol = “https://”;
if (myRequest.protocol EQ “HTTP/1.1″) {
protocol = “http://”;
}
host = myRequest.headers.Host;
script = cgi.redirect_url;
if (LEN(cgi.query_string)) {
queryString = “?” & cgi.query_string;
}switch (host) {
case “aaaa” :
newHost = “bbbb”;
break;

case “cccc” :
newHost = “dddd”;
break;

default :
newHost = eeee;
break;
}
</cfscript>

<dl>
<dt>The page you asked for on</dt>
<dd>#protocol##host##script##querystring#</dd>

<dt>might be found on our new and improved server</dt>
<dd><a href=”#protocol##newhost##script##querystring#”>#protocol##newhost##script##querystring#</a></dd>
</dl>

Did you know that you can use the ColdFusion Administrator to view your JRun log files?  It’s quite convenient to view the contents of these files while you are troubleshooting issues with ColdFusion or JRun.  This article will describe how I’m configuring my servers to view these log files.

I’ve installed JRun into a file system on the server.  Then, in the [jrun-root]/logs folder, I have created a unique folder name for each of my defined JRun server instances.  My unix startup scripts are written to send the standard out log files to the [jrun-root]/logs/[servername] folder.  Additionally, I’ve configured each JRun server to write a unique log file for each log level.  This allows me to get a specific log file for metrics, errors, and informative log entries.

I then simply configure ColdFusion to write its log files into the same folder.  Once the server starts up, I have all of my ColdFusion AND JRun logs in one directory.  Better yet, when the CF Administrator lists the log files in the current logging directory, it sees all of the JRun log files.

Virtual Host Headers and ColdFusion Multi-Server Installation

Mark Kruger recently had an excellent post over at the ColdFusion Muse about Virtual Host headers.  While his post showed how to do this in IIS, I wanted to show you how to do it in Apache and at the same time, combine it with a  ColdFusion Multi-Server Installation.

Apache has enjoyed Virtual Host Header support for serveral years now.  All that is needed is to modify your httpd.conf file to use the <VirtualHost> directive.  Beginning with Apache 2.0, the recommended configuraton for these virtual hosts were put into a separate file:  typically: ‘./conf/extra/httpd-vhosts.conf’.  You’ll find that the main httpd.conf file has a line near the end of the file to include this extra confirution file.  It works just like CFINCLUDE, so the contents of ‘httpd-vhosts.conf’ are appended in-line with the main httpd.conf file.  Be default, this line is commented out, so you’ll need to un-comment it to get Virtual Hosts to work in Apache.

I add a slight twist to this general setup.  I create a folder named ‘virtuals’ under my Apache Configuration directory.  I then modify the main htpd.conf file to use this line:

Include virtuals/*.conf

This tells Apache to include ALL of the files in the virtuals folder that end in ‘.conf’.  I can now create multiple virtual host files with explicit names.  For example, in my virtuals folder, I’ll have the following lines:

dev.site1.com.conf
dev.site2.com.conf
www.site.com.conf
www.site2.com.conf

Each of these files contains a single VirtualHost directive, telling Apache how to configure each virtual site. I prefer to have the configuraton for each site in it’s own configuration file, rather than having them all bundled together in one large file.  Two benefits of this approach are:  1) I can put SSL support in the sites that use the SSL certificate, 2) I can remove supprt for a site by simply renaming the configuraton file to something that ends with an extension other than ‘.conf’.

ColdFusion Multi-Server Installation
We all now by now that we can have multiple ColdFusion deployments (with a context root of /) on our server by createing multiple JRun Servers.  This allows me to have a single CF deployment for ’site1′, and a separate CF deployment for ’site2′.  Consider the following JRun servers defined in [jrun-root]/servers/.

site1
site2

Each of these JRun servers contains a separate copy of ColdFusion from an expanded EAR deployment.  Each of these two JRun servers also use unique HTTP, Proxy, and JNDI ports.

Now, when you use the JRun Web Connector utility to configure Apache (or by using the default installation to modify Apache for you), you’ll find that the Apache Configuration file contains the following lines:

LoadModule jrun_module modules/mod_jrun20.so
<IfModule mod_jrun20.c>
JRunConfig …
JRunConfig Bootstrap 127.0.0.1:51002
JRunConfig …
AddHandler jrun-handler .jsp .jws .cfm .cfml .cfc .cfr .cfswf
</IfModule>

I’ve specifically designated the two really important configuraton items here.  There are probably 5-10 line in the IfModule directive.

This tells Apache to send all requests ending in specific extensions (.jsp .jws .cfm, etc…) to another server on a specific proxy port (127.0.0.1:51005).

You can copy the <IfModule> block from the main httpd.conf file into your individual virtual hosts files in the virtuals folder.  By changing the port number in the JRunConfig Bootstrap line, you can now use a different JRun Server, and by extension, the specific ColdFusion deployment to use for your virtual site.

This allows me to deploy different versions of ColdFusion for different sites, or to keep the ColdFusion configuraton settings completely unique and different for each site that I am supporting in Apache.  I can now grant people access to the CF Administrator for site1, and keep them from prying into datasources and other settings that are used by a different team on site2.