This installment in my series detailing how my local web development environment is set up is going to deal with my application server setup. After visiting with several folks at the cf.Objective() conference this year, I was convinced that I needed to configure my ColdFusion 8 installation in “multi-server” mode.
There are a few advantages to installing ColdFusion in multi-server mode versus stand-alone mode. The main advantage for my situation is that multi-server mode lets me configure an instance of ColdFusion to match each of my clients’ environments. Imagine if you had two clients each with legacy applications that you need to support. If both clients had (as many development shops did at one time) created a ColdFusion mapping called “CustomTags”, you’d have a serious issue on your hands when trying to set up your local environment to work on these applications. Since ColdFusion can only point a mapping to a single folder, if you have installed the stand-alone version of ColdFusion, you’d either have to put all files from every “CustomTags” mapping in one folder, or constantly be updating the directory that mapping points to. Neither are good solutions and would ultimately lead to problems. With multi-server install, you get the ability to create a completely separate ColdFusion environment for each client, and therefore the ability to create a “CustomTags” mapping in each that points to the correct directory. The same applies to datasource connections and all the other settings managed by the ColdFusion administrator.
The typical install location for ColdFusion using the multi-server installation is /Applications/JRun4/servers/cfusion on the Mac and C:JRun4serverscfusion on Windows. I’ve changed the install location on my setup to /opt/JRun4/servers/cfusion to more closely match the configuration when installing into Linux or Unix machines. This also has the advantage of getting the JRun4 directory out of my Applications folder–there is enough stuff in there already as it is.
I also don’t have ColdFusion services start when I boot my laptop. Since I regularly switch clients during any given period between reboots, I manually start all my ColdFusion instances in a terminal session with the command
/opt/JRun4/bin/jrun -config /opt/JRun4/bin/jvm-serverName.config -start serverNameThat looks like a lot of typing so I’ve created a “shortcut” in my .bash_profile so if I type cf-serverName I get the above line. I’ve created one of these shortcuts for each of the ColdFusion instances that I have configured. It’s important to note that, while it’s not strictly necessary to include the -config argument in the command, if you ever want to have two or more instances of ColdFusion running at the same time and need to use the debugger, you’ll want to have separate jvm.config files created for each. The reason for this is that, under normal circumstances, all instances of ColdFusion share the same jvm.config file. The TCP port definition for the debugger is located in jvm.config. The first instance to start up will take that port while the second and successive instances you try to start up will fail to start because that port is already in use by the first.
When ColdFusion is installed and configured to work with Apache, the installer adds several lines to the Apache httpd.conf configuration file. Essentially, what this does is connect every Apache virtual host that will be created to the same instance of ColdFusion. Obviously that defeats the purpose of having multiple instances of ColdFusion. Below are the lines that are active in my main httpd.conf file (there are others there, but I’ve commented them out and for sake of space, won’t include them here):
# JRun SettingsLoadModule jrun_module /opt/JRun4/lib/wsconfig/1/mod_jrun22.so<IfModule mod_jrun22.c> AddHandler jrun-handler .jsp .jws .cfm .cfml .cfc .cfr .cfswf</IfModule>Notice that there is no mention of anything specific to any instance of ColdFusion. The lines below are from one of the virtual host config files and map this virtual host to a specific ColdFusion instance. They are located inside the element.
JRunConfig Apialloc falseJRunConfig Serverstore /opt/JRun4/lib/wsconfig/2/jrunserver.storeJRunConfig Bootstrap 127.0.0.1:51002The most critical of these three lines is the last. Each ColdFusion instance will respond on a specific TCP port. By default, the first instance created during installation (cfusion) runs on TCP port 8300. In the jrun.xml file for each instance, toward the bottom, there is a section that lists settings for proxy service that JRun uses to communicate with the native web server. There is a key there that specifies whether the proxy server is disabled as well as a key that specifies the TCP port for the proxy server. The 51002 in the example above is the port number from that line in the jrun.xml.
The next installment in this series will discuss the database system(s) that I use locally.