With the recent availability of a pre-release version of Adobe’s ColdFusion 10 CFML engine, I am going to be doing a bit of comparative exploring to see how this upcoming version lines up against the current 9.01 version. My intent is to install and configure ACF10 on one or more of my development systems in a manner where it can run alongside the currently-installed ACF9 so that I can get a feel, in particular, for any performance differences between these two versions and to ensure that when ACF10 is officially available, any compatibility issues with our CFML-based applications have been addressed.

My current development systems are Mac OS X and Linux boxes, running ACF 9.01 under Apache’s Web server. I will install ACF10 in a stand-alone mode in order to be able to run both servers concurrently. In this mode, ACF10 will be running with the bundled Apache Tomcat server for use as both its application server (replacing the JRun application server historically used with ACF) and as its Web server.

The first portion of this effort, then, will focus on getting ACF10 and Tomcat configured to function as needed in my development environment. With that in mind, I will be exploring the following Tomcat-related configuration needs and blogging about them (as well as anything else of interest I stumble into) in the coming days:

• traffic logging
• something equivalent to Apache httpd’s Alias/AliasMatch directives (required for our applications to function correctly)
• enabling compression for Web-traffic
• enabling server-side includes (SSI)
• secure cookie handling (e.g., the “secure” and “httpOnly” cookie options)
• IP-based access restriction (e.g., restricting access to the CF administrative interface  and other content to only the local system); see this subsequent post for a second take on this;
• disabling directory listings
• specifying the default Web document
• setting up user folders

You can see that list is a mix of security-related settings and configuration settings related to how our application folders are structured (and the desire to run these applications through both the new Tomcat/ACF10 stack and the old Apache/JRun/ACF9 stack).

In terms of structure, all of the applications reside in a folder outside of the Apache webroot, and are found via a set of aliases. The folder structure below that top-level folder is set up as follows (with their corresponding application URL’s listed in parens):

• appGroup1
  • common
  • app1a (http://localhost/app1a/)
  • app1b (http://localhost/appab/)
  • app1c (http://localhost/app1c/)
• appGroup2
  • common
  • app2a (http://localhost/app2a/)
  • app2b (http://localhost/app2b/)
  • …
  • app2n (http://localhost/app2n/)
• app3 (http://localhost/app3/)
• shared

Within each of the application groups “appGroup1″ and “appGroup2″, the “common” folder contains assets shared by the applications in the corresponding group; this folder is aliased into each of the individual applications within the group to appear as if it were nested below the application folder (e.g., http://localhost/app1a/common, http://localhost/app1b/common). All of the applications reference the “shared” folder as a root level folder “/shared” (i.e., as http://localhost/shared).

Further, most of the applications have a default document that relies on SSI to function properly as part of the applications’ respective authentication and security framework. I also do all of testing and prototyping in a folder immediately off of my home folder; I will need to have that folder served by Tomcat/ACF10 just as it is currently under the other stack.

Finally, a caveat: I am a complete noob when it comes to Tomcat, so I will be learning as I go. I am almost certainly going to find sub-optimal ways to make portions of the work. If you see such mis-steps and have recommendations for other and/or better ways, please point them out in the comments on each post.

We have our work cut out for us. Stay tuned.