Damon Gentry’s Blog

From time to time, my dad will send me (read:  forward) some jokes via e-mail.  I got one yesterday and found it good enough to pass along.

Continue Reading »

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.

At work this week, I achieved a significant milestone.  Well, not ‘cure for cancer’ significant, but important to me nonetheless.  I have divorced myself from JRun.  I’m now running 100% GlassFish as my J2EE server of choice.  I’ve not yet implemented this on any production servers, but I have managed to get my local workstation configured with Apache, GlassFish, and ColdFusion.  Here’s a quick primer.

Continue Reading »

Assume the following code:

<cfcomponent output="false">
  <cffunction name="looptest" output="false"  returntype="numeric" access="public">
    <cfloop from="1" to="25"  index="i">
      <cfif i EQ 11>
        <cfreturn i  />
      </cfif>
    </cfloop>
    <cfreturn i  />
  </cffunction>
</cfcomponent>

What value would you expect to be returned from this function? It will either be 11 (if the cfreturn tag exits the loop), or 26 (if the cfreturn tag does not cause the loop to exit).

I tested this and got 11, which implies that a cfreturn value inside of a loop will cause the loop to break. I couldn’t find where this is documented in the CF 8 LiveDocs.

As a follow up to my last post, I thought I’d share some more information about running ColdFusion under GlassFish and Apache.

I mentioned that there were 2 options to configure Apache to send dynamic (CFML) requests to the J2EE server. They were: mod_proxy + mod_rewrite, and mod_jk. I have decided to use mod_jk for its flexibility and wide choice of configuration options.

I began by having the GlassFish server configured to support AJP13. This is a pre-requisite to using mod_jk and Glassfish and is documented fairly well here (http://weblogs.java.net/blog/jfarcand/archive/2006/03/running_glassfi_1.html).

I then created a worker.properties file with the following contents:

worker.list=glassfish
# Set properties for tomcatcf (ajp13)
worker.glassfish.type=ajp13
worker.glassfish.host=localhost
worker.glassfish.port=8009

This simply tells the JK module that I have 1 server (named ‘glassfish’), running on the host ‘localhost’, on port 8009, and that it can accept AJP13 connections. I can, at this point, define additional servers on alternate hosts or port numbers. For now, let’s stick to my single server.

Next, I started with a very simple JkMount directive:

JkMount /cf8/* glassfish

This informs Apache that all HTTP requests that begin with ‘/cf8/’ should be routed to the GlassFish server defined in the ‘worker.properties’ file. At this point, I had a working environment.

However, I want to configure my server such that Apache handles all static requests (images, PDFs, CSS files, etc…), and hand over the heavy lifting of dynamic requests to the GlassFish server. To do this, I began by modifying my JkMount directive:

JkMount /cf8/*.cfm glassfish
JkMount /cf8/*.cfc glassfish

Now, Apache will only hand requests off to GlassFish if they are in the /cf8/ folder and have an extension of .cfm or .cfc. Next, to ensure that all the static web content is available to Apache, I had to add an Alias directive:

Alias “/cf8″ “c:/var/j2eeapps/cf8″

This seems to have done the trick.  In addition, I get the benefit of my ‘DirectoryIndex’ directive, which tells Apache that the ‘index.cfm’ template should be processed first when requesting a URL that begins with /cf8/.

The nice thing about this configuration is that I can define multiple J2EE server applications and route them to any AJP13 back-end compliant J2EE server.

With last year’s announcement that JRun 4 would no longer be developed, I began looking for alternative J2EE platforms on which to deploy ColdFusion.  As a long time user of ColdFusion, I knew that there were plenty of options to choose from, but I wanted to take some time to evaluate the open-source options.  

Technically speaking, there is only one (supported) open source J2EE platform for ColdFusion 8, and that is JBoss, and even then, only on Windows, Linux, and Solaris.  While that should cover most OS’s I’d use to deploy ColdFusion in a production environment, I happen to develop on OS X.  Furthermore, I’ve never been comfortable using JBoss.  I know it’s not much of an excuse, but the lack of a decent administration interface rubs me the wrong way.  At least BEA and Sun have their act together there.  Also, with the RedHat / JBoss marriage appearing to be a disaster, I’m not sure I want to be making any bets that I’ll be deploying ColdFusion on JBoss in the near future.

So, I’ve turned my attention to GlassFish.  For those who don’t know, GlassFish is the open source version of the Sun Java System Application Server.  In other words, you can get GlassFish for free, or you can pay for the commercial product and get support.

Installing GlassFish is pretty easy to do.  Simply download a jar file into a directory of your choice, extract the ‘/glassfish’ directory with a simple java command, and then run an ant script to complete the setup.  That’s it.  I was able to search the online documentation to find examples for startup scripts and how to make GlassFish a Windows Service.

Deploying ColdFusion to Glassfish is pretty simple as well.  I chose to run the CF installer and have it spit out a .war file.  I then extracted the cfusion.war file into a folder of my choosing.  In my case, I extracted the contents into a folder under my CFEclipse workspace.  Then, I used the GlassFish Administrator to deploy a WAR application by selecting that folder.  At this point, I can navigate to http://localhost:8080/CFIDE/administrator.

Next, I decided to put Apache in front of GlassFish.  There are 2 options here, mod_proxy/mod_rewrite, or mod_jk.  I’m still evaluating both at the moment, but I think that mod_jk has more flexibility and may be more user friendly than mod_rewrite.  I’m using mod_jk at work (under Windows), and mod_proxy at home (under OS X).

I’ll be posting periodically on any issues I discover along the way.  But so far, ColdFusion under Glass(fish) is looking pretty good!

I got an e-mail today from a reader (yes, an actual reader!) asking about some posts I did last year on Transfer.  Unfortunately, I lost those posts.  I’ll be trying to get them back online within the next few weeks.

I happen to find myself in the very enviable position of helping a web development team define the processes, procedures, and tools that they will use to do their daily work.  We have been discussing everything from source control to project management, to release management.  We’ve not yet deployed everything, but I wanted to share our current progress with those who might be interested in this sort of thing:

Web Server
We chose Apache as our web server because we work in a mixed platform environment.  Also, Apache can be extended and tweaked in so many ways that are very useful to our work.  Modules like mod_proxy, mod_ldap, mod_dav are just dead simple to setup and configure.

Source Control
We chose Subversion as our revision control system.  I’m still kinda of new to Subversion, but I’ve worked with Rational ClearCase and Visual Source Safe before.  My take:  Subversion rocks.

Putting Subversion behind Apache allows me to leverage mod_ldap to authenticate all actions in Subversion against our LDAP server.  This means that each and every user action in Subversion is tracked and recorded.  It also means that I can easily grant access to the repositories by username or group membership.

Bug Tracking, Issue Tracking, and Project Management
We’ve been evaluating Atlassian Jira and have decided to license it for our team.  Installation and documentation are superb.  Integration with Subversion took about 15 minutes.  Add the Mylyn plugin to Eclipse, and you can now integrate your development activities (SVN commits) with Bugs, Issues, or Tasks assigned to you in Jira.  How cool is it to review an old bug and find a list of the files that were committed into the repository that ‘fixed’ the bug, along with the commit date/time, and the name of the developer who committed the code?

BTW:  Atlassian has a very sweet suite of products that are work checking out.

Eclipse, CFEclipse, Subclipse, and Mylyn
From one IDE (Eclipse), our team can work on ColdFusion, Java, PHP, or Perl code from a revision control repository (Subversion) with no need to switch between the IDE and Windows Explorer to update or commit code.  Also, we can update project tasks in Jira without having to leave the IDE.  Eclipse is the new Outlook (the one app that should be running ALL the time.)

Putting it all together (Poor AMEX ripoff):

Apache - $0
Subverion - $0
Eclipse - $0
CFEclipse - $0
Subclipse - $0
Mylyn - $0
Jira - $2400

A robust set of tools that allows our web development team to work on several projects, effectively and efficiently: Priceless.

As part of my new job, I’ve been asked to setup a monitoring and alerting solution for our web infrastructure.  The team was initially using a limited (free) version of Servers Alive, but we were having problems with the alert notifications.   Additionally, we were limited to monitoring only 10 hosts with the free version.

I’ve been reading about a product name Hyperic HQ.  It is an open source J2EE application that monitors your application infrastructure and provides alerting and escalation workflows.  I’ve only been playing with the product for a few days, but I am highly impressed.  Here’s my review in a nutshell.

Continue Reading »