Today at work we realized that there is a ColdFusion 8.0.1 hotfix (subtly different from ColdFusion 8.0 hotfixes) that we haven't applied and would explain and resolve an issue we've been noticing.

Specifically, I'm talking about the ColdFusion 8.0.1 Cumulative Hotfix 2 which has been available since October of 2008, and blogged about a little bit yesterday, but otherwise seems to have mostly flown under the radar since its release.

Why is this update important for framework users in particular? For one of the included fixes:

Fix for memory leaks with CFCs stored in memory scopes. Note, this does not eliminate need for proper use of VAR scope in CFC methods.

This is a subtle way of saying that there are memory leaks associated with storing CFC instances into "memory scopes" (Application, Session, and Server). Every framework that I've used or looked at — and probably all of the ones I haven't — store the core of their functionality as CFC instances in the Application scope; and that means that over time (if your application lives long enough), your java heap will grow out of control and server stability will suffer.

That means if your application uses Fusebox, Model Glue, Mach II, Coldbox, ColdSpring, Transfer, Reactor, DataFaucet, onTap, Co-Op, or other frameworks, you probably have a memory leak. To be fair, it's a small leak in our experience; but a leak is a leak, right?

Left un-mended, a pinhole could sink an oil tanker.

Not just for Framework users.
Any application that stores CFC instances in Application, Server, or Session scopes would likely benefit from this update. For example, that includes BlogCFC and Mango Blog, even though neither uses a framework. Carefully consider what applications you're running or writing, and make sure you update if necessary.

In addition, there are 14 other issues that were resolved and included in the hotfix, so it's worth 15 minutes of your time to read the release notes (very brief, I promise) and decide if it applies to you.

How do I know if I already have it?
In your ColdFusion administrator, there are a few icons in the top right corner. Clicking the "i" icon shows system information. A ColdFusion 8.01 Standard Edition, with the first cumulative hotfix installed looks like this. Specifically, look at "Update Level":

After applying hotfix 2, it will look like this:

Why has it been so obscure since October 2008 (21 weeks and counting)?
There has been some speculation that its release was right around the last round of Adobe layoffs, and this may have caused a disconnect between the Engineering team and the Customer Care team, which is responsible for authoring and publishing Tech Notes. It's entirely speculation at this point, but seems possible and not at all unlikely.

Help spread the word. Hopefully, we'll eventually get Adobe to pick up the pace and list this update on the ColdFusion 8 hotfixes page.

ColdFusion 8 added support for this.mappings and this.customTagPaths as per-application settings in Application.cfc, something many developers including yours truly will tell you was a god-send.

But did you know that they can be relative?

I stumbled on this — uh, feature? — and I'm still undecided on whether I like it or not.

I was doing some work for a client whose production environment is on shared hosting. When working on shared hosting, I never hard-code directory paths. Today the root directory of the site might be C:\sites\clientName\www\, but if a hard drive crashes or the server is upgraded, it could switch drive letters or folder locations in the blink of an eye with no warning, and all of a sudden your applications stop working, your websites go down, and your business isn't making money.

For that reason, I make judicious use of expandPath. Not only does this protect me from lack of control of the production environment, it allows differences between development, staging, and production environments without a giant switch-block that changes all sorts of settings based on environment.

So my Application.cfc code looked something like this:

this.name = "testHarness"; this.customTagPaths = ''; this.customTagPaths = listAppend(this.customTagPaths,expandPath('./customTags'));

Do you see what I did wrong there? I used a relative path starting with a dot, which indicates that the path is relative to the current directory. This is syntactically correct and doesn't cause any CF errors, itself. The only reason I was surprised at all was, because of a bad assumption.

The expandPath function just translates a string to the absolute path (at runtime), and my (bad) assumption was that it would run once on application load and live for the life of the application. If this were the case, the dot wouldn't matter because the path relative to the root would be set and used throughout the site. On the contrary, it runs on every page request, and is relative to the currently executing base (more on this later) template.

Where you'll run into problems with this syntax is when you try to use a custom tag from a page in a sub-folder. For example, take the following theoretical website:

Application.cfc
index.cfm
customTags/
    someTag.cfm
someFolder/
    somePage.cfm

Assume that Application.cfc sets this.customTagPaths in the form I specified above, and someFolder/somePage.cfm tries to use your "someTag" custom tag, you'll get an error similar to this:

ColdFusion attempted looking in the tree of installed custom tags but did not find a custom tag with this name. If you are using per-application custom tag mappings, ensure that per-application settings are enabled by the administrator.

What's happening is that ColdFusion is looking for someFolder/customTags/somePage.cfm, which doesn't exist.

I suppose you could use this to your advantage, if you had a need for it. For instance, you might have a layout custom tag that you wrap your pages with to make sure they all have the same header, navigation, and styling; but sub-pages in folders get slightly different navigation.

Having two custom tags in two different directories that are found relative to the current template is probably a bad idea as far as maintenance is concerned though. Joe the Programmer isn't likely to notice your "." in the custom tag path, and even if he does he's not likely to realize that it means all custom tag paths are relative; unless you make heavy use of the pattern and it becomes a standard in your organization.

But, it works. I tested it by creating two custom tags that indicate who they are:

/customTags/someTag.cfm:
I am the surface custom tag

/someFolder/customTags/someTag.cfm:
I am the deep custom tag

And to see the results, I used the same-named custom tag from each of our two pages. I also wanted to see what would happen if I included the deep page:

/index.cfm:

/someFolder/somePage.cfm:

The output of /index.cfm was as follows, indicating that the custom tag relative to the base template was used in both cases:

I am the surface custom tag
I am the surface custom tag

And the output of /someFolder/somePage.cfm was as follows, indicating that the custom tag from the sub-folder customTags was used:

I am the deep custom tag

This brings up yet another potential issue. If you have this relative custom tag path organization in use, and later decide you need to cfinclude a sub-page onto your home page to highlight it for the week, it won't use the same custom tag that it does in the sub folder. That's not to say it will fail, because if you're clever you can again use that to your advantage.

But again, being overly clever is often more of a problem than it is a good solution. In my opinion, you're better off with one custom tags folder and two different custom tag names.

Last year I got my first ColdFusion certification, just in time for a new version of CF to come out and make me feel like I was behind again. Since the test is only $150, I figure I might as well upgrade to a CF8 certification.

I've heard rumors that thanks to Ray, the CF8 exam is much tougher than the CF7 exam. And since it's going to be harder, and I really don't want to lose the "Advanced" level, I'm going to prepare pretty hard. Last year I did self-study, and it was pretty overwhelming — there's just so much material and you don't get a great idea for what to study. This year, I'm going to prepare with the recently released CF8 Exam Buster training software.

I've already got it installed and gone through the first test, and I'm confident it's going to help me be prepared for the exam. I'll post again after I get my exam results and let you know what I think of CF8 Exam Buster, and whether or not I maintained my "advanced" level certification.

I've been working on a project where we're using Illudium to generate some objects (beans, dao's, and gateways) to speed up our development process. We also happen to be using ColdFusion 8, which means we have access to great new features, like the primary key return value from an insert query.

During a presentation on how to use Illudium and how it saves us time and effort, my team saw that I was: (1) Inserting a record, then (2) Creating a bean with all of the properties of that record except its missing id value, and then (3) searching for the matching record — so that I could use its ID in related code; and asked if there was any way to improve that. That's when it dawned on me that CF8 returns the primary key value (in most cases — Oracle just returns the "RowID" which can be used to look up the primary key), for just this reason. By the end of the day I had modified the XSLT template for the Create function in the DAO object that's packaged with Illudium to return this value instead of true or false indication of success — and with no prior knowledge or experience with XSLT.

It was simple to extend my code so that it wouldn't error on earlier versions of ColdFusion (instead of the primary key value, it will return 1/-1 for success/failure), and also to account for other database types. All types documented by Adobe are supported here.

Here's the updated code for create.xsl. Note that the majority of what I changed is at the end:

[viewcode] src="create.xsl.txt" showsyntax=no geshi=xml scroll="yes" scrollheight="300px" link="yes" [/viewcode]

And here's an example create function I made from the ART table of the CFArtGallery example datasource:

[viewcode] src="fn_create.txt" showsyntax=no geshi=cfm scroll="yes" scrollheight="300px" [/viewcode]

Brian Rinaldi, the creator of Illudium, offered to help me out if I got stuck, but honestly he's done such a good job architecting Illudium to be easily extended that it was a piece of cake. Thanks again for the awesome code generator, Brian!

I recently sat down to put together a blog post covering how to "bridge the gap" between a 404 and onMissingTemplate (because a .cfm file has to be requested before the web server hands the request off to ColdFusion), and I thought that it would make a great article for dzone, so I submitted it there instead.

If you're intrigued by onMissingTemplate, but frustrated that it doesn't work for just a requested folder, go check it out!