I will propose that they should be done from oldest to newest. Here's why.

If you look at the list of CF security hotfixes offered here, you may wonder whether to start with the most recent ones, or the oldest ones. If you look at their respective technotes and zip files closely, you may find that some are truly independent of the others. But it's also a reality that some do supercede the others. That may be obvious to some, but I wanted to offer a case in point.

Consider the hotfixes for APSB11-14 and APSB11-04. If you look at the zips for these, you may notice that they offer a few files (in the web-inf/lib directory) that appear identical in name (log4j.properties, esapi.properties, validation.properties, commons-fileupload-1.2.jar, and so on.) If you had applied the later one first, you may then wonder if it's significant if you then want to apply the older one.

Well, those files are in fact identical (I did a compare). But the files in the CFIDE associated with each hotfix are in fact quite different and so the later ones would supercede the earlier ones.

So you would NOT want to do them in the wrong order (older before newer). It's just not always clear from the technotes whether this is an issue to worry about, so I wanted to share it here.

This is not the place for discussion of how complicated CF hotfixes are. That's been discussed to death in many places. If you didn't know, Adobe is indeed addressing the problem in the next release, currently code-named Zeus. You can read about this and 50 other currently publcized Zeus features in a talk I did. And note that they have said they will be back-porting some of that to earlier releases.

Hope it's helpful to someone. If you may have a different experience or opinion about the order of applying security hotfixes, feel free to share it.

PS I have written previously about easy mistakes you can make in applying any CF hotfixes, and how to avoid them. See CF911: Are you finding CF (or CF Admin) busted after applying a hotfix? Three possible reasons. I have also written about the challenges of trying to "skip" cumulative hotfixes. You may want to read them if you've not yet done so.

But again, please hold off on any comments about the complications of CF hotfixes. There's nothing more to do than deal with the situation as it is and await Adobe offering a better solution.

Both CF 9.0 and 9.01 run on older JVMs (and therefore need this update). And are you on CF8? You're not left out: Adobe even has confirmed this update can be applied to CF 8 and 8.01, too!

Update: Since posting this note some have kindly pointed out that Java has been updated beyond update 24, and indeed to Java 7. I did realize that, but didn't mention it simply because u24 is all that Adobe has (for now) certified CF to support. Still, for the sake of completeness, I want to clarify this now and I'll address it more in the final section below.

Old news, but not everyone knows

Someone mentioned today on a list that they'd seen news from Oracle of this important bug (and fix) for the JVM, which can cause someone to crash the JVM using a particular URL string. He also noted that while Oracle had released the fix some months ago, he lamented that "This issue doesn't seem to have gotten too much interest from Adobe."

I explained that in fact Adobe had addressed it, also some months ago.

Adobe's response

Adobe offered a technote on the issue in March 2011.

In fact, they not only confirmed support for (and recommended updating to) the fixed JVM version, 1.6.0_24, but they even (for the first time in years) approved updating to this JVM version for CF 8 and 8.01. Since those ran on very old JVM releases, which had problems not fixed until JVM update 10, this was really good news.

But as his note conveys, word just had not gotten out as much as it could. Beside his thread on that list, I hope now that this blog entry will help reach more people.

More about the bug

If you want to know more about the bug from a CF perspective, check out this blog entry (from several months ago by David Stockton, of cfconsultant.com). He explains the problem/risk as well as shows how to cause the problem (to confirm when it's fixed), as well as some useful extra info on using FusionReactor to help diagnose it.

How to update the JVM for CF

So if you're now persuaded, you may wonder how you go about updating the JVM. You may fear it's like doing open-heart surgery. It's more like getting a mole removed. :-) It could go wrong, but will barely be noticeable if done right.

There are many blog entries that walk through the few simple steps. Find out more from Ryan Stille, Mark Kruger, and Adobe, to name just a few.

While it's not too hard to do, there are just a couple of potential gotchas: be sure to get the JDK not the JRE, and pay attention to the special path format that's needed when pointing to the JVM on Windows.

So if you're on CF and have not yet updated the JVM, seriously consider it.

What about updates beyond u24?

I did realize that, and do appreciate their wanting to share the info. I'd not mentioned updates beyond 24 simply because I would not propose (myself) that anyone now update beyond the release for which Adobe has certified CF. (At least not until compelling reasons arise and substantial community testing suggests it may be safe, as happened with CF8 and the u10 update. Even then, you are risking being out of bounds for support by Adobe, so should make such a change with caution.)

The whole point of this entry was that u24 HAD in fact received Adobe's blessing, for CF 8 and 9, which was pretty compelling and seemed to have been missed by some when it happened earlier in the year.

Anyway, one more tip: in case anyone may find it hard to locate the older updates (like u24) on the Oracle site, here is a link (which works, at least, for now):

http://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-javase6-419409.html

Again, be sure to get the JDK (development kit) not the JRE (runtime environment) among the options listed there.

The "good" news is that there are at least two really common explanations of what may have happened, which I'll explain them here. Once you consider them, you may find either that you can confirm this is what happened (and fix it), or if nothing else you can keep it in mind if you're ever applying them yourself in the future.

I help people solve this very problem often, whether on CF mailing lists or in my independent consulting as a CF troubleshooter. And I've been meaning to post these thoughts for months but as you'll see below, there's a fair bit to consider, if you look beyond what one may try to communicate in a tweet or simple mailing list answer. After doing just that today on yet another forum, I decided to offer the expanded explanation, and hope that it may help someone.

First, some background.

What's different about recent CHFs, SHFs, and HFs (past couple of years)

Before addressing the problem, it would help to understand what's different about hotfixes (for 8 and 9) the past couple of years which can make this an issue in the first place.

It used to be that most hotfixes (CHF, SHF, HF) were just a single jar file, that you would (per the technote for the hotfix) just either upload using the CF admin "system information" page or drop into the appropriate \lib\updates folder.

But in recent years, the hotfixes have gotten more complicated (solving important security problems, often), including now often needing to update entire directories, whether in the WEB-INF or the CFIDE (where both the CF Admin and also various UI features for CFML are stored).

Well, if you make a mistake in doing that (updating those directories, or doing it in the wrong place), then you may find that some part of CF is busted, whether the Admin or perhaps even part of your app (which relies on finding those properly updated files within the CFIDE directory).

Let me make one important note before, some jump in here to (reasonably) bemoan the situation.

Note that Adobe is addressing this with the next version of CF

Yes, it is unfortunate that these problems can happen. And the good news is that Adobe is addressing it in the next release of CF. They have pointed out in a number of recent public presentations and blog entries that they will be adding an automated hotfix mechanism in the next release, for now code-named Zeus.

Also, at the 2011 RIACon conference, during the Adobe keynote, it was indicated that they planned to offer a form of this hotfix installer for CF 8, 8.0.1, 9, and 9.0.1 as well.

But until then, the following may prove helpful.

Now, back to the problem at hand: how you may make mistakes in applying hotfixes that may leave things busted. My observation (in helping lots of people with this problem) is that the challenge is primarily three-fold.

Challenge 1: Updating the wrong directory CFIDE

The first problem could be that you have installed hotfixes related to CFIDE into the wrong place. It's surprisingly easy.

I noted earlier that often the hotfixes may now have you update code in the CFIDE directory. Most know that to be where the CF Admin is stored. But it's also where various files are stored (by default, unless you move them) to be used by various UI elements of CF, in CFIDE\scripts. For instance, all the ajaxy things are stored there, as are the older cfform elements. There's also CSS, XSL, and other stuff there. That's why those things can break (silently, since it's the client's browser that now can't find what it wants, or finds the wrong version of a file, based on CF generating code that expects to use the "updated" versions.)

Well, here's the problem: when the technotes tell you to extract the zip into the CFIDE directory, they often leave you to figure out where that should go.

And the problem is that you may have many. For one thing, when you install CF, you're asked if you want to use the built-in web server, or an external one. If you do the former, then the CFIDE is put in the [cf]\wwwroot. if you do the latter, it's stored wherever you tell it is your web server root, whether inetpub\wwwroot, or htdocs, or wherever.

And if you use the Multiserver form of deployment, you may find that even if you install CF initially to integrate with your web server (in which case it would put the CFIDE in perhaps the inetpub\wwwroot, if/when you create new instances, they by default each have their own CFIDE deep within the instance, such as [JRun4]\servers\[instancename]\cfusion.ear\cfusion.war\CFIDE.

So when you run the update, you need to be POSITIVE that you are updating the one that your CF instance is really using, which means you may need to update many.

And if you're not careful, you may actually find you currently have a CFIDE directory in both kinds of places (and more), either because you have had multiple versions of CF installed, or someone has copied the files from one place to another to "fix" a problem. Then also, some admins (and hosting providers) even repeatedly copy the CFIDE (or perhaps just CFIDE/scripts) to the docroot for different web sites, trying to help with some other issues.

The upshot then is that you could easily have more than one CFIDE.

But it gets better: you can also set things up so that you can access the CF Admin either through the built-in web server, or through the external web server, or both. So besides the question of where the CFIDE lives, there is also the matter of where your web server (whichever you're using) is expecting to find the CFIDE.

And this goes for the CFIDE/scripts. Whether an admin has made multiple copies of it, or just manually added a virtual directory definition to their web server, this means that what matters most (for "finding" the CFIDE to update) is where the web server says it's looking.

Now, before someone gets too burdened with these prospects, note that I'm just explaining some of the many things that CAN happen. You may have a simple environment, and only one (or maybe two) places where the CFIDE lives.

So where to look to know where to update the CFIDE?

Given all the above, what are you to do?

Well here's one tip (not mentioned in the technotes): if you look in the CF Admin, you will find in the Mappings page that there is in fact a mapping for where *CF* at least thinks that the CFIDE is located. So first thing before applying the hotfix, check out that mapping, and at least be sure to update THAT location. That may be all you need.

But second (and even despite doing the above), do look at your web server (IIS or Apache), and see where THEY think that the CFIDE is located. Remember, that's what your browser will end up using (whether for the Admin, if you access it via those web servers, or for your end users running apps on your server). The point again is that they may show different CFIDE mappings, either for different sites, or within different sites.

Yes, it's lamentable. But the problem is caused by people doing things on their own that they need to remember they've done. And no, I doubt Adobe really will be able to fully resolve this, since they'd have to go digging in your web server to find the info. (They could, but should they? since they didn't cause the problem?)

And consider too that it may be that the different CFIDEs are leftovers from different CF versions you may have installed, and each may have been installed differently (one using the built-in web server for the CF Admin, one using the external web server).

So as the captain in the old show, "Hill Street Blues", used to say to his patrolmen after their morning briefing, "be careful out there".

Challenge 2: Extracting the zips at the wrong level

This next challenge is different from the above, and yet applies to that step (extracting the zip for the CFIDE). But it also applies to extracting the zip for the WEB-INF, or any other directory where a hotfix says to extract a zip.

Here's the problem: it's possible that even if you point your zip extracting tool (winzip, izarc, winrar, copy/paste, whatever) to the "right" directory, you may mistakenly (or the tool may) extract the zip in such a way that what you extract is not at the level you point to, but one level below it.

I've seen it happen, to myself and others. (And some zip tools are more prone to it than others, especially winrar, in my experience.)

Here's the thing, if the technote says, for instance, to extract from the zip the web-inf directory, if you're not careful you may end up putting a NEW \web-inf under your current one! So you end up with \web-inf\web-inf. That will NOT, of course, update the needed files within the "real" \web-inf directory.

And of course the same could happen when you extract the CFIDE. You could end up with CFIDE\CFIDE.

Indeed, I've seen people have it happen when they extract the jar to the lib\updates.

So again be VERY careful, and double check things as you proceed.

Challenge 3: Be sure to do ALL the steps in the technote

Finally, another mistake I've seen people make is that they miss one or more steps in the technote. Again, these recent hotfixes have gotten more and more complicated, and have many steps.

Again, the automated hotfix mechanism in Zeus should address that.

But until then, it's incumbent upon you to make sure you follow each and every step, carefully and completely. Hope the above helps.

(BTW, there's a slightly related issue: you may also think you can skip over intermediate CHFs, like from having none to going to CHF 2, or going from CHF 1 to CHF4, etc. I addressed that separate problem in a past entry, "CFMyths: "If/when I apply Cumulative Hotfixes, I need apply only the latest CHF, right?"">.)

What you can do, if it's broken

So the steps above are what to be aware of as you're going through the hotfix update process. But what if you did it and it's busted, and you found this note after the fact?

Well, I hope you can use the info above to simply double-check what was done. For instance, check if the directories have mistakenly got things in the wrong place (like if you see a web-inf\web-inf).

Look also at the dates of the files in the zips, and make sure that the dates you show (where files SHOULD BE) are in fact the same dates.

As for the CFIDE issues, besides the above, you may also benefit from just doing a search of your hard drive to find any and all CFIDE directories. You may find many. Again you can check for which are being used by your web server and make sure they are correct for whatever version of CF you mean to be running (for that URL on that web server).

Hope that helps. Or did I leave anything out? Any questions? Comments? Let me know, either way. Like I said, I'd been holding off publishing this because I knew there was a lot that deserved to be covered and it would take time to write. I felt pressed to get it out today, and am trying to remember now all that I've had in mind over the past couple of years on this topic. :-)

Let me know how I did.

In this second entry, I'll address the separate but related problem, particularly if you're running CF as a Windows service, that you may find you get timeout errors from the Windows Services panel itself. I'll share some tips to help with that, which I share often with clients of my independent consulting as a CF troubleshooter.

The first thing to understand is that there is indeed a timeout (configurable) for how long the Windows Services control panel is willing to wait. Beyond that, though, there are some 3 more tricks you can use to avoid that timeout.

Update: I should add that a commenter suggested that another solution was just to kill the task. Um, yeah. I knew that, of course. :-) But the point of this entry, like the last one, is when you DON'T just want to kill it. In particular, I made the point in the last entry that if you want to find out *why* CF is taking so long to shutdown, then you need to let it run to completion to see if it may log some diagnostics. See the last entry for more on that.

But yes, as Russ Michaels noted, sure, you can also just kill the task. I will say I try to avoid doing that whenever possible, to let CF end gracefully, unless I'm forced to kill it for urgency sake.

Note that these tips can be helpful for everyone who runs CF as a Windows service, and indeed for anyone running any application as a Windows service.

Tip 1: There is a timeout set for how long the Windows Services panel will wait

So the first thing to note is that, yes, the Windows Services control panel has a fixed duration for how long it's willing to wait for an action (start, stop, or restart) to take, which is configurable in the registry. If the service control action you request does not finish in time, you'll get an error like "The service did not respond to the start or control request in a timely fashion", with associated event log errors like 1053, 7000, 7009, 7011, and so on.

And technically, you should be able to control that timeout via a registry key, called ServicesPipeTimeout, which is discussed in this Microsoft technote and defined in HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control.

Sadly, though I've tried it on multiple machines, I'm not finding it to work.

The technote shows clearly how to either update or add it (if it doesn't exist), including noting that you need to choose the "decimal" option to see the value, which is in milliseconds. The technote does note that you must restart Windows for that change to take effect (and I have done that, and double-checked the value, keyname, and location.)

If anyone has more thoughts on this, why it may not be working for me, feel free to share. Still, you will find many blog entries and discussions proposing this, for CF and other servers, so maybe it will work for you.

The technote doesn't clarify what the default is if the key is not there at all, though I've found some mention that it's 30 seconds. I suppose it could vary by version of Windows (anyone know for sure?).

(Note that there is another key you may see (or hear about) set in the same location: WaitToKillServiceTimeout. That is NOT related to this discussion. That key, instead, controls how long Windows should wait for any/all services to stop when you shutdown Windows itself, which is interesting to consider for itself, but not related to this particular blog entry about Services control panel timeouts.)

Of course, all the usual warnings apply about messing with the registry. But it's the solution, if you need it.

So again, this ServicesPipeTimeout registry key would seem to be the one that controls how long the Services panel is willing to wait for a requested action to finish.

Do beware that it's system-wide setting, controlling all services. What may be good for you (CF) may not be good for all services, so be careful. Second, again, note that the server will require a restart for that to take effect.

Whether it works for you or not, the remaining tips should be helpful.

For instance, if you can't change that registry settings, or don't want to, or you find some day the Services panel is still taking too long to stop a service and you worry it may timeout (the control panel), then there are 3 more tips I often share with my customers (and now you, dear readers).

Tip 2: Use stop/start, instead of restart

Again, if you're being plagued by a service start or stop taking a long time, here's something you may not have considered.

Most often when people want to restart CF (or some other service) they will use the "restart" action in the Services panel. That's logical, of course.

But consider that when you have a problem with the action taking too long (stop and/or start, since a restart does both), both have to finish in that configured timeout time (above).

You can help matters by doing not a restart but a stop and start separately. That way, each action can take whatever the max time is that's configured (per above) to do just the one action.

Sure, it's a little painful. You do have to wait for (and notice) the stop before then doing the start. There's also the risk that even the stop may take too long. I'll offer two more tips related to that.

Tip 3: Close the progress bar before its "times out"

This one may not be as obvious, but it does really help. When you have a start/stop/restart action (for the Windows Services control panel) taking a long time, you risk hitting that timeout above.

But notice that Services panel shows a progress bar indicating the duration of the action you've requested. Here's the tip: if/when it's about to reach the end of its indicated time, note that you can hit the "close" button.

That will prevent it complaining about not being able to stop the service. (And BTW, I've seen situations where hitting that timeout limit not only gives an error but even causes the start/stop/restart buttons to be disabled, requiring a restart of the box!)

Once you close the progress bar, you can use the refresh button in the Services panel (or f5) to watch for when the service goes from "stopping" to blank, meaning it's down. Same for when you "close" it while starting a service: it will go from "starting" to "started".

Tip 4: Consider not using the Services Panel at all

Still another tip (which I use regularly) is that you don't actually HAVE to use the Windows services panel to stop/start Windows services. You can do it from the command line (or a shortcut or batch file).

To be clear, I'm not talking about starting the program itself from the command line (CF, as I've been discussing in these last 2 entries), but the Windows service that starts the program. It's a subtle difference.

As an alternative to starting the Windows Service (for CF) using the Service control panel (Control Panel>Administrative Tools>Services, to be clear), you can use a command line command like this, which I use to stop CF:

net stop "ColdFusion 9 Application Server"

The service name is whatever is shown in the properties for the service you want to stop. (And of course you would use a "start" command instead to start the service. There is no "restart" command, buy you could create a batch file to do both.)

You can run this from the command line (Start>Run>cmd) or as a batch file, but I prefer instead to just setup a Windows shortcut, which you can do by right-clicking the desktop and choosing new>shortcut.

That will prompt you for the command (it just asks you to "type the location of the item", but just enter that command above). It will then ask for a name for the shortcut. I call mine simply "stop cf9".

And while you can then execute it by going to the desktop and double-clicking it, a niftier tip is that with more modern Windows versions (2008, 7, Vista), when you hit the the Window Start menu, it now offers a search feature, and you should be able to type "stop cf9" (or just type "stop " and leave it to pop any shortcuts you've created this way to stop various services.)

So why do I like this approach, of stop/starting the service from the command line instead? Because what happens is that a window pops opens (the traditional black background for DOS windows, so easy to observe) and it shows the stop (or start) taking place, however long it takes (which may be very fast). The key benefit is that the window will close on its own when the action is done (however long it takes). I just watch for the stop to be done, and then I do the start.

There is a possibility, of course, that there will be an error in the shortcut or batch file (or perhaps as a response to the correct command), in which case the window will close leaving no chance to see the error. In that case, I just go to the command line (Start>Run>cmd) and execute the same net stop or start command to see what the error is.

To be clear, using this command-line doesn't stop you or others from using the Services panel.

Conclusion

All that said, though, again, if the reason you need to worry about all this is that your CF Service is taking a long time to stop, and you want to find out why, then I would point you again to the last entry I did, In my last entry, CF911: Is your ColdFusion service taking too long to shut down? Find out why.

Hope all that was helpful, whether you use CF or not. Please do let me know in the comments below.

First, this one will help you perhaps find why it's so slow. You may just have been looking in the wrong place for that diagnostic information. Second, the next entry will offer tips to handle on better handling the situation (that the Windows service is slow to stop, and timeouts in the Windows Services panel itself) which you may need to consider until you do solve the root cause problem (or in case it happens again for other reasons).

(Note that most of this info will apply as well if your problem is that CF's taking a long time to start, also.)

As some of you know, I do CF server troubleshooting as an independent consultant. In helping several people a week, this is a fairly common complaint. This also came up on a mailing list today, so I decided to offer these thoughts here.

Check the logs--but not the "CF" logs

Generally, the explanation for why CF is taking so long to stop (and perhaps also, to start) will be logged (if you are patient enough to wait for it to really go down. More on that in a moment.)

Of course, if you run CF from the command line, then the error would be shown in the command line console. But nearly everyone running CF on Windows will instead be running it as a service. In that case, things get more challenging.

The challenge is that the information about startup/showdown of CF is NOT detailed in the "CF" logs (those shown in the CF Admin, or found in the [cf]\logs directory or buried deep within an instance in Multiserver mode). Those logs (like application.log and exception.log) are often not helpful for system-level problems.

Instead, you need to look in the equivalent of the "console" logs, which in CF 9 or before are found in [cf]\runtime\logs\*out*.log or [jrun]\logs\*out*.log. (In Zeus (the next version, not yet released, which has been publicly shown as running on Tomcat), the will be in the "logs" directory, but as a new file: [zeus]\logs\start.log.)

I refer to these as CF's "console logs" (though as you can see that's not not the formal name) because again this is where CF writes messages that would have been written to the console if you'd started CF from the command line.

(Some will note that there is also info written to the Windows Event logs, but nearly always it just says to see the CF logs. Sadly, it doesn't clarify which logs, or this need to let it end, which is why I'm writing this entry.)

Others will note that if you did start and stop CF (not the service, but CF itself) from the command line, rather than a a service, then you would see any such error messages in the command prompt window. That's true, but it doesn't help you if you already have CF running as a service when this happens. It also would not be an effective way for most to start/stop CF on a continuous basis. But it may be useful for debugging the problem if it happens consistently. See the "configuring and administering CF" docs for more on running CF from the command line.

The key point in this entry is that you will nearly always find something in the log just before CF finally shuts down.

Note that you DO need to let CF shut down, to get that log message

Given what I just said, you will generally need to be patient and to let CF shut down completely to see the message (written in the log just before it finally shuts down). I know this will dishearten some: in the pressure of the moment they just want CF to go down ASAP and so many will just kill the task to be done with it (though of course, sometimes that doesn't work either).

The problem with killing the task is that you then may not see the needed log message explaining why it was waiting so long.

When my customers are complaining of this issue, I try to persuade them to make the painful sacrifice (at least one time) to just go ahead wait and let CF really stop completely on its own, so that they get that log info.

Yes, I realize it may take a few minutes, or even several in some situations. And there are a couple of problems related to that (who can afford that time? and what about the Windows Services timeout). Let's take them one at a time. Because if you need to solve the problem of CF taking a long time to shut down, you have to at least try to get this diagnostic info.

What if you can't "afford the time" to let it stop completely?

As for "who can afford the time" to wait for it to shutdown, here's a tip: if the problem happens fairly consistently (pretty much whenever you stop CF), then just wait to do it (this experiment, where you'll let it take as long as it needs) later in your evening or on the weekend (assuming that's a slower time for you.)

Of course, if you have a cluster of servers, then taking one instance offline is less a problem.

But what about the Windows services panel timeout?

The bigger problem with waiting for it to completely shut down is that you can't "wait forever" for a Windows service to stop. The Windows control panel has a fixed time that it's willing to wait, and if you exceed that it gives an error message (or worse).

The good news is that there are solutions for that, but that's really a whole different subject, and I'll tackle that as a separate entry next (coming up right away).

So what sort of reasons might you find that CF doesn't shut down quickly?

As for what errors that you may find to explain why CF is taking so long to stop, there are many and that would be good fodder for a follow-up blog post. I'll try to get to that in coming days/weeks.

Still, I suspect that most of you will be able to understand what the messages say on your own, now that perhaps you may finally be able to see them. :-)

But certainly, until I do get another entry together on the possible reasons it's slow to shut down, feel free to ask here in the comments or email me directly (charlie at@carehart.org).

If you're looking for how to configure CFBuilder to open htm files with the CFML editor, see that other entry. This one instead is about the related idea of having CF (the server) process htm (or other) file extensions. There are certainly pros and cons.

First, how to configure it in CF

Since I suspect some of the first people to come look at this will be those who want to do it, for any reason, the good news is that yes, you can do it, and it's been documented by many. I won't rehash the details, but instead will point you at any of several resources that do. It's not heard, though it does require a restart of CF (and perhaps your web server) to take effect.

First, Adobe documented it long ago. It's a pretty old and barebones article. It makes only a passing reference to the need to also change the configuration in your web server. To be clear, you do need to make the needed changes to the web.xml file if using an external web server like IIS or Apache, but the point is that you also then therefore need to also make changes in that external web server.

Fortunately, a more modern Adobe technote does address that additional detail. And this solution works for CF 6, 7, 8, and 9. (With Zeus being built on Tomcat, it may well be quite different then.) Do be careful to look closely at the values, as some may change from release to release ("macromedia_mapping" vs "coldfusion_mapping").

Other writers also addressed the issue over the years. For instance, Steven Erat blogged more about it, as did Peter Bell, Brian Anderson of Hostek, Steve Cross, and Tony Weeg, to pick just a few.

My point is, clearly many do find this an intriguing idea, for whatever reason. So why might one want to?

Why people might want to do this

There can be several reasons why people want to do this, some reasonable and some questionable.

I suspect that many delight in (or are compelled to explore) the idea of "hiding" their server implementation. By using htm files rather than cfm ones, no one need know they use CF (by the URLs of their page requests).

Of course, they could use still some other extension, whether some new one not used by anyone else, or perhaps one that others do know, and the solution above works for that as well.

For instance, I've known people who have configured things so that files with the php extension were handed to CF: not because they wanted CF to process PHP code, of course, but rather just because they did NOT use PHP and therefore just wanted to make it seem to the world that they did.

They may hope to throw hackers off the trail, or may want to avoid having to explain to folks that/why they use ColdFusion (sad that this should be the case, but some have felt the need).

Why people might not want to do this, and counters to such concerns

For all those who like the idea, there are probably more who spurn it, again for a number of reasons.

I'll say that while on the surface their concerns may seem clear-cut, as with so many things, "it depends". Those who might still want to try the alternative configuration for whatever reason might offer some reasonable counters to those concerns. Again, I'm not on either side in this debate. I'm just reporting observations for consideration. :-)

The concern of processing all HTM files as CFM, and the counters

For one thing, those who do not like the idea would point out that having htm files processed by CF runs the risk that now EVERY htm file will be processed by CF, even if it has no CFML in it at all, which of course would add overheard for the page execution time and would also add useless overhead to CF.

A counter some may propose is that one could set things up to use *.html extensions for "real" html pages and *.htm for "html/cfml hybrid pages, so that hopefully at least you only have CF process what you really think should have CFML.

Still others would note that they could also control whether and when they do this in the web server, so that perhaps it's only some website or some directories for which this configuration change (htm files being handed to CF) is made.

The concern that some things other than CF might be confused by the change

I noted above that some might use this approach simply to define not htm files but instead some other extension to be processed by CF. There's no real performance impact to doing that.

But it does raise the specter that some things may be confused by the change, if they expect to look for/find/use only cfm extensions. Possibilities include editors, log analysis tools, and so on. (I addressed how to change CFBuilder to open HTM files with the CFML editor in the last entry.)

Might there be other solutions, though?

Even with these concerns and their counters, some might want to propose still other solutions to achieve the goal of obfuscation (hiding the fact that you're running cfm files, if that's the main goal of the above). Let's take a look at a couple.

Using no extension at all

For one thing, some could just set things up so as not to use a file extension in their URLs at all, relying for isntance on the web server support of default documents (like index.cfm) to point to one file in the directory. No, it won't work for everyone, but I in fact do that frequently on my own site, such as for http://carehart.org/presentations/, http://carehart.org/articles/, or http://carehart.org/consulting/. I never bother with the index.cfm, as the web server figures it out for me.

Again, though, that approach only works when you can have one file per directory.

But someone has shown using a variation of the technique above (changing the extensions handled by CF) to have CF process requests for files that have extension at all. It's "out of the box" thinking, but I share it if it may interest someone.

Another solution: URL Rewriting

I'm sure some have been champing at the bit the whole time they've been reading this article, because they know something that perhaps others do not. Another solution for all this trickery above would be to use URL rewriting instead, so that you don't change the file extensions but instead you just don't use any at all in the URL.

With that approach, you configure things on your server (often via an extension to your web server) so that when people ask for one file, they're really sent to another. So if someone asks for url abc (whatever that is, in terms of domain, path, file, path_info), they are instead shown the result of processing file xyz (whatever that may be, to suit your interests), but the browser URL still shows the url as abc.

URL Rewriting can completely hide the underlying server implementation, or whatever level of it you choose, such as hiding what extensions you use, your use of query string/URL variables within code, your use of deep directory structures, and so much more.

This is not the place to discuss and debate all the pros/cons and even alternatives for URL rewriting, but I'll note that I do have a category for them with several alternatives (free and commercial, for Windows and Linux) at my CF411 site's category for URL Rewriting Tools .

BTW, the URLs for my cf411 site are themselves processed by a rewrite rule, though slightly different from what was just discussed. Note that that url I just shared, http://www.cf411.com/urlrewrite, ends up as http://carehart.org/cf411/#urlrewrite. You'll see that in the browser. Not only does the domain change (I wanted to people to get to it as cf411.com), but you also end up within a given subdirectory of my carehart.org site (the cf411 site is really just a subset of that main site).

And finally the URL ends up showing use of a page anchor (the #) to jump down in the very long page to the section chosen.

I wanted to be able to share URLs without all that noise. You've got to admit that cf411.com/urlrewrite is just smoother than carehart.org/cf411/#urlrewrite. :-)

Of course, I could have implemented the rewrite to keep that "new" url hidden. I just didn't bother. But if you're new to url rewriting, do remember that you CAN have the "resulting" url hidden from the user.

So, there you have it. A problem, some solutions, some concerns, some counters to those, and still other alternatives. I'm sure some are thinking "man, I never thought there could be so much to consider for this simple idea". But as always, there are just lots of things to consider, and as a troubleshooting consultant, it's my job to find, understand, and offer solutions to such problems.

But I could well have missed something significant. I know that some people may have far more experience with this particular problem (and to be honest, this is not one I help people solve often. It came up today for one user, so I researched and wrote here about it.)

But I do recognize that there is often more to a problem than seems to most at first, and I wanted to share the observations with any who may appreciate it. That's how I roll. Let me know what you think.

Update, Recording: Note that this session was recorded. You can view it here, but note that you must login with an Adobe ID to see it.

And I'm presenting a session tonight, Tuesday September 13, at 7pm Eastern, on "Understanding and Using the ColdFusion Server Monitor".

As many of you know, I'm pretty much a fanatic about the monitor, especially about truly understanding elements of it that many miss. And so in my talk this will not be just a dog and pony show, but I will talk about practical experiences with it, though presented to either those new to it or experienced with it.

Note that the times for all these devweek sessions is shown (on the Adobe site) as being Pacific time, so again mine is at 7pm, not 4pm, Eastern.

And yes, the sessions are being recorded and seem to be made available the next day.

Finally, beware that there is no one URL you can use to join in on all the Connect sessions, nor can you get the Connect session URL by going to the event page (via the first link above). Instead, you must register for each event (free) from that first page, to get each session's Connect URL--and you'll want to do that at least several minutes in advance of any session to have time to register, get the email, login, etc.

See you then.

PS Hey, while we're talking monitoring, note as well that if you've not heard, FusionReactor has come out with its new release 4, which has lots of great additions, especially FREC (or the FR Extensions for CF) which cause FR to grab and log lots of great info that the CF Server Monitor only shows and never logs. I'll be blogging about FR 4 soon, but plenty to see on their site. and FusionAnalytics is also just about to release, really!

I won't be discussing these at this talk, focused solely on the server monitor, but as I always tell folks, each tool has its use and often a single shop can benefit from having both (like I do, as do many of the clients I help with troubleshooting). You can find more from me about FR here in my blog. And I'll have lots more to say about FA and FR4 more soon.

I'll detail the limits per version/edition below.

I'll also offer a (possibly surprising) workaround that can allow you to get even more requests through IIS, even for a single web site.

(Before I elaborate on that, note that there is a separate issue if you're finding that CF doesn't let you see more than 25 requests at once. That's instead due to a setting in CF/JRun, the maxworkerthreads setting. For more on that, see this blog entry.)

That said, this is a problem which could affect anyone regardless of the app server they may be running behind IIS. (And yes, I do realize that for some, the answer to this problem will be, "see, that's another reason to run Apache." We get that. Let's just focus on this problem for those who choose/have to remain on IIS.)

Background

I was doing some load testing noticed that I couldn't get beyond 3 requests running at a time. I suspected the problem may be IIS.

So at first I tried just making the same requests against CF's built-in web server (such as might be running at port 8500, which can be enabled/configured during CF installation or manually).

Sure enough, CF could execute more requests at once (up to the "simultaneous requests" setting) through the built-in web server.

So that told me the problem had to be in IIS. I did some digging and found the documentation that affirmed what I was seeing.

(Some may recall there used to be a limit of 10 for IIS on Windows XP, so it may surprise some to run into an even lower limit on later Windows versions.)

IIS 7 does have a "request execution limit"

The first resource I found was with respect to the limits in Vista. This page says specifically: "With Starter and Home Basic editions of Windows Vista, the simultaneous request execution limit for IIS is three for Windows Vista Home Premium. ...For Windows Vista Business, Enterprise, and Ultimate edition...the simultaneous request execution limit is ten. ..With server editions of Window, IIS 7.0 has no request execution limit."

But I'm sure some reading this will be using Windows 2008. I found a page discussing its limits: for the Basic & Starter editions: 3 requests, for Premium: 3, for Pro: 10, and for Server: unlimited.

I happened to be running Windows 7 when I hit the limit, and while I've not found a document stating the limits specifically for Windows 7, I can again confirm the same limit of 3 on my copy of Windows 7 Home Premium, so I'm sure things are the same, to whatever degree the edition names parallel the other versions. (It's curious that the learn.iis.net page above does discuss both Vista and Windows 2008, but makes no mention of Windows 7.)

A workaround for this limit: multiple worker processes

With respect to this limit, here's a valuable bonus tip that I've not seen documented anywhere: the limit is really per application pool, or more technically per worker process. So you can certainly get more request simultaneously against your box by using multiple app pools.

But perhaps you want to have more requests against a single site, which obviously can be connected only to a single app pool. There's still good news: you can increase the number of worker processes per app pool in the "advanced settings" for a given app pool (right-click on the app pool), increasing "Maximum Worker Processes" from the default of 1. (Some will recognize that as being the same as what was known as "web gardens" for app pools in IIS 6.)

For those new to them, whether creating new app pools or more worker processes for an app pool, for each new worker process, you'll see a new w3wp.exe in task manager.

A caution, for those using ASP.NET, about setting more than one worker process per app pool

Finally, there's a caution to consider if you decide to increase the number of worker processes. At least back in IIS 6, I documented that if you're running an ASP.NET app using sessions that are "inproc" (or in memory), the default, there is a problem with using multiple worker processes (web gardens), in that the sessions are not replicated among the worker processes. That may not be an issue for the OP, so I'll say you can learn more at an entry I did a few years ago.

Did any of this help you? Let me know below.

Here's the next, related, myth:

True or False: "If/when I apply Cumulative Hotfixes, I need apply only the latest CHF, right?"

For instance, let's say you're currently running CF 9 update 1 or CF 8.0.1 and discover (perhaps due to my last blog entry) that you had never applied any of their associated CHFs. It would seem you should just be able to apply the latest CHF and not bother with anything related to the previous ones, right?

Answer: Well, yes and no.

There may be manual steps in skipped CHFs

Technically, yes, you need only apply the latest CHF in terms of getting whatever hotfixes are included in the chf jar.

The problem is, there are sometimes multiple steps involved in applying a given CHF (especially in CF 7 and 8), or there may be specific hotfixes that are indicated at the end of the CHF technote as requiring a manual step. I'll explain the differences in more detail in a moment.

If you have NOT done those manual steps, you WILL still need to do them, even if you "skip" that CHF in question.

This is definitely the case for CF 8.0.1, which had 4 CHFs, and also for CF 7.0.2, which had 3, and for each release some of the CHFs had manual steps. It's not the case for CF 9 Updater 1 (9.0.1) CHF2 and 1 (this sentence added as an update since this entry was originally posted.)

The table below details which CHFs, specifically, have manual steps. (For CF 8.0, none of the 3 CHFs had any manual steps. I'll explain later here why I can't tell you for CF 7.0.1 or 7.0, and why this isn't an issue for CF 6.1 and 6.0 users because they didn't have CHFs at all to potentially "skip".)

This isn't a mere technicality: it could be critical

Some may think I'm being pedantic in raising this concern, but take my word as a CF troubleshooting consultant: some of these manual steps are very important ones, so it's really unfortunate that some people may be "skipping" them inadvertently. I help people with this very problem at least once a month.

For instance, in 8.0.1 CHF 4, there are both a bootstrap.jr needed, some manual hotfixes, and some related to security fixes. In 8.0.1 CH 3 there are important fixes related to image processing problems (which have plagued many, who are missing this fix).

And perhaps most important, for those running CF 7.0.2, there was a surprisingly critical (yet innocuous looking) manual step in its CHF 2, and this one hotfix may be the explanation for many people suffering inexplicable memory leaks in that release. I'll discuss each of these more in a moment.

What do I mean by "manual steps" in a CHF? How would you tell if they are there?

What I'm talking about here is either of different kinds of manual steps in a given CHF. I'll first explain them, then reflect it more succinctly in a table to follow.

1: A simple, single-step CHF

First, by comparison, note that for most CHFs, applying the update merely involves downloading a zip, extracting a single jar, and using that to apply the update (whether by uploading it in the CF Admin "system information" screen, or by dropping it into the appropriate lib/updates directory, each of which are discussed in the technotes. I'll note that many don't realize they can apply HFs and CHFs merely by dropping their respective jar into the appropriate lib/updates directory: the technotes sometimes only mention this fact in the "uninstalling" section, where they point out that the files to be deleted have been placed there by using the Admin interface.)

2: A multi-step CHF

As a second example, in contrast to the simple one-step CHF above, sometimes the technote for a CHF will have more steps which indicate that you need to manipulate multiple files in one or more extra steps.

As I mentioned above, the CHF4 for 8.0.1 is an example of that. This is the kind that is most disconcerting to me.

3: A CHF with multiple zips

A third example is really a variation of the last one: some CHFs don't have so much "multiple steps" but instead have multiple zip files that need to be extracted.

The CHF1 for CF 9.0.1 is such an example. Note that its steps 6-9 involve updating files in WEB-INF/cftags and CFIDE directories.

In such a case, we just need to hope that any next CHF will offer those same files (and as an update since this entry was first written, CHF2 DOES include the same--though perhaps updated--files in its zips).

Unfortunately, the technote for CHF2 doesn't make this entirely clear, but I compared the extracted zips to confirm it.

4: A CHF with separately applied individual hotfixes

Finally, in some CHFs, there may still be only one chf jar file, but after the simple list of steps for applying that, the technote may then also list additional individual hotfixes which still need to be applied, separately from the hotfix.

These may be listed either at the top or bottom of the CHF technote (though usually, they are listed at the bottom). There are several CHFs of this sort, and again I will detail them for you later here. But first, let me stress an important example of this.

A Critical example from CF 7.0.2

A critical (and sadly, oft-missed) example of this is the 7.0.2 CHF 2. At the bottom of that page are listed several such "manual" hotfixes, and among those is one extremely important one. Unfortunately, the wording on the page doesn't make it sound very worrisome (and frankly, seems incorrect from my experience). In testing I did at the time, this was a hotfix which when implemented would stop a bug where CF would hold memory from a file upload until CF was restarted--a true memory leak. Adobe did fix the problem in CF 8, and said so, which is how some of us became aware of it.

But even if you DID read the CHF technote, you may not sense the severity. The link to the hotfix labels it as "Update for cffile memory leak", and the text preceding that says, "This hot fix is for a potential memory leak caused by cancelling cfuploads in progress with ColdFusion MX 7." In my testing, though, it really had nothing to do with "cancelling cfuploads". It was any file upload (where you had an input type="file" in a form that was used to post a file) to a CF page, whether you cancelled it or not!

Further, if you go on to read the page about the hotfix itself, its own title might lead some to think it applies even less to them, "Hot fix to make ColdFusion release memory properly with file uploads and CFC's stored in application, session or server scope". Is this meant to be read that the file upload has to happen in a CFC stored in a shared scope? If you thought so, again, you may shrug it off as a seemingly rare situation, but again in my testing back then, it did not matter. Any file upload to a CF page held memory for the size of the file uploaded, until CF was restarted. To make matters worse, the text in the body of the technote says (in my mind, incorrectly), "ColdFusion does not release the memory properly with file uploads when a reference to a CFC is stored in the application, session or server scope in the same page".

Take my advice: ignore all that mumbo-jumbo. If you're still on CF 7.0.2 and you missed that manual hotfix listed in CHF 2, go apply it! It may be the reason you've had CF crashing for running out of heap. (And if you're still on CF 7, then of course you should move up to the free 7.0.2 updater. Again, I discuss and link to updaters in the previous blog entry.)

Again, though, this is just one example (7.0.2). There are similar examples of such similarly-required separate individual hotfixes in some other CHFs for other releases.

When will adobe stop the madness with an automated installer?

Well, the good news is that as Adobe has been talking about the upcoming new release (currently codenamed "Zeus"), one of the most significant new features is an automated hotfix mechanism. This isn't the place to elaborate on that (since few details have been shared), but I may do another blog entry in the future, if someone else doesn't first. (If you're reading this and know somehow who has, share it in a comment.)

What CHFs in what releases have manual steps?

So, given all the above, which CHFs do you need to worry about, if you are intending to "skip" them? To help make things easier to track, following is a table that identifies each CHF for the most recent releases, and it indicates for each CHF whether it has any manual steps. If it does, then if you are skipping it to move to a later one, you need to be sure to apply those manual steps:

So you can see that this problem is most significant (for now) for those on CF 7.0.2 and 8.0.1.

I'm not going to list 7.0 or 7.0.1, because for one thing, the links to the technotes for their CHFs are currently failing for me (as offered from the CF 7 hotfixes page), so I can't look at them to confirm if they have manual steps. It's reasonable to assume they do. Another reason not to list 7.0 and 7.0.1 is that, again, if you're on those releases, you really ought to update to 7.02 (for free), if not to 8 or 9.

You may notice that I don't list CF 6.1 or 6, either. Well, in fact, the whole concept of cumulative hotfixes was added only as of CF 7, so this concern (about trying to "skip" CHFs) just doesn't apply to those running CF 6 or 6.1.

And don't forget to check for any subsequent hotfixes after whatever "latest" CHF you apply

Finally, this entry has focused on what manual steps you may need to do related to previous CHFs you may be trying to "skip". But separate from those, keep in mind as well that there may be one or more individual hotfixes that have come out since any given CHF was released (or you may have applied it).

Part of the challenge is that, since the technote for a given CHF is written when that CHF is released, it obviously does not at that point in time reflect any new hotfixes posted after that. I suppose we could argue that Adobe should warn you (at the bottom of each CHF) to also go check if there are any subsequently released hotfixes.

For now, it's incumbent upon you to keep an eye on the hotfix page for the version you are using. I listed them in the last blog entry, but here they are again:

• "ColdFusion 9 : List of Hot fixes" (for 9.0 and 9.0.1)
• "Hot Fixes | Cold Fusion 8 and 8.0.1"
• "ColdFusion hot fixes (MX 7 through MX 7.02)"
• "ColdFusion Hot Fixes (MX through MX 6.1)"

For example, as of this writing, there are 2 hotfixes listed after (chronologically) the latest CHF for CF 9, CHF 1. There are also 2 hotfixes currently listed after the latest CHF for CF 8.0.1 (CHF 4), there are 4 hotfixes after the latest CHF for CF 8.0 (CHF 3), and there are 2 after the latest CHF for CF 7.0.2 (CHF 3). So again, if you think you're "at the latest CHF", make sure there may not be still more hotfixes that apply to you. For more information, see the corresponding page in the links immediately above, for whatever version of CF you're running.

Finally, with respect to watching out for individual hotfixes within a given release, note that you generally cannot watch only the main "CF Updates" page. That generally lists only installers, updaters, and CHFs. (That said, there is at least one "input sanitization" hotfix shown at the top of the list of CF 8.0.1 CHFs. )

Hope all that's helpful. Let me know what you think.

First myth up for consideration:

True or false: "If/when I download CF to install it from scratch, the installer has all the latest fixes (updaters, at least)"

Answer: False (generally). For instance, if you download CF9 today (Dec 2010), you still get CF 9.0, released originally in Oct 2009. You don't get the latest updater (9.0.1 as of this writing, released July 2010), though its existence is at least mentioned on the page, nor of course does it then include any hotfixes or cumulative hotfixes.

Why not, you may wonder? I'll explain more in a moment, along with more about hotfixes and updaters as concepts (and where to find them specifically, for each CF release).

About this CFMyths Series

First, I want to introduce this new series, CFMyths. Today's entry, though prompted by a question on a mailing list, is in fact a frequent source of confusion for folks. Indeed, it's one that I've covered (along with many like it) in a CFMythbusters talk that I've given at various events. Of course, relatively few see such talks, and even though I offer the details in the slides, available on my site, many never dig into those, either I think, so I've long meant to create some blog entries from them.

Today's question prompted me to go ahead and start that series. (And I know I still owe readers the continuation of a CF911 series on memory problems that I started last month. Part 2 is now written. I just needs to refine it. This topic got my attention, and once I started writing, well, here you go. :-)

"So why is the currently available installer not necessarily 'the very latest version'"?

It's about logistics, really. CF runs on many platforms (OS's, web servers, databases, and different releases of each), so it's expensive for Adobe to create new installers. This is why the base version may be left there for quite a while, with you being expected to apply any subsequent updaters or hotfixes. That will surely surprise many, but it's the way it's been for some time (except 8.0.1, when a completely new installer was offered, in addition to one to update those already on CF 8.)

So it's incumbent upon you, when you download a given release, to pay close attention to what version it is. It will be reflected first in the installer filename, such as coldfusion_9_WWE_win64.exe. It will also be listed with the specific version number as reported in the CF Admin and logs once it's installed (such as 9,0,0,251028 for the base version of 9.0, or 9,0,1,274733 for the base version of 9.0.1). You'll then need to check to see if there may be any updates, hotfixes, or cumulative hotfixes. The same is true for 8.0.1, too (whose base build number is 8,0,1,195765). I'll point you to the updaters and hotfixes in a moment.

"What are all these terms? Hotfixes, updaters, CHFs?"

Before proceeding, it may help some readers if I explain the terminology of the various updates for CF that may exist:

• Hotfixes are individual fixes to specific problems (typically offered as a single jar file, such as hf801-76563.jar, and for which there is usually an individual technote, such as this one for that hotfix, which is a recent fix--Oct 2010--for CF 8.0.1)
• Cumulative hot fixes (CHFs): when there have been many hotfixes, they will typically be rolled into a cumulative hotfix which includes several(such as the CHF 1 for 9.0.1, which can only be applied to CF 9.0.1, not CF9). There's no fixed number of hotfixes which will trigger Adobe to create a CHF. They are usually deployed also as a single jar, and you are expected to remove any individual hotfixes that are included. Again, the technote for each hotfix will explain these things. As the name implies, they are also cumulative, such that CHF 2 includes all the hotfixes that CHF1 included (with a caveat, discussed below). CHFs do not included new features
• Updaters: When there have been some number of CHFs, they will often be rolled into an update/updater (like 9.0.1, 8.0.1, 7.0.2, 7.0.1, 6.1). Updaters are always executable installers, and they often do add some minor new functionality to CF.

Adobe has a page that explains more about these terms generically.

Note that when looking at hotfix/CHF filenames(such as hf801-76563.jar), you can tell by its prefix whether it's a hotfix (hf) or CHF and what version it's for (8.0.1, in that example.)

Indeed, that brings up another potential gotcha: be careful about inadvertently applying a hotfix/CHF to the wrong release, or leaving an old HF in that's been obviated by a CHF that includes it. I discuss the potential gotcha of applying the wrong hotfix/CHF for the wrong version in a blog entry, You may have mistakenly applied an 8.0 CHF on a 8.0.1 CF server, and not realize it!

Finally, the Adobe technote page about each hotfix, CHF, or updater will each explain how to apply that particular update. Again, I'll offer links to the key pages for different release updates in a moment. First, there are a couple of other common misconceptions I want to address.

Phew: I bet some readers thought all this should be pretty straightforward, and may be surprised to learn all these details. It's the kind of thing I often find myself helping my customers correct, and again it also often comes up in questions on lists/forums. You might think we've covered all there is, but sadly, there are still some more gotchas.

"At least when I apply an updater, that includes all hotfixes that preceded it, right?"

Well, not necessarily. For instance, when the CF 7 updater 2 (7.0.2) came out, Macromedia decided not to bundle an updated set of JDBC drivers in the updater. It was up to you to download and install those as a manual hotfix. I blogged about that back at the time, in 2006.

Again, the logic was understandable: there were considerable changes introduced by the drivers (licensed from a third party), and forcing it on existing users could have been troublesome. If you wanted the updated drivers, you needed to download (for free, from Adobe) and install them yourself. The installer notes clarified this, so as always, it pays to read the updater documentation carefully. There are often multiple documents for any new updater, including a FAQ, release notes, and more.

"Well, at least with Cumulative Hotfixes, I need apply only the latest, right?"

Again sadly, no, not necessarily. Let's say you're on CF 8.0.1 and never applied any of its 4 CHFs. You may think you can just apply CHF 4 and not bother with anything related to the previous three. Unfortunately, there are often manual steps within any one previous CHFs which you WOULD still need to apply.

In fact, this question (and answer) is important enough that I'll create another entry on that so it's not lost here (where this entry's title will lead some to think it applies only to installing CF from scratch).

"OK, so where do I find these updaters I need to check?"

Fortunately, there's one primary page you can keep an eye on, but technically there are various pages you may want to check, depending on your CF version, to get more or less detail.

First, the main "CF updates" page can be found here. It not only includes updaters and CHFs, it even has them for CF 9, 8, 7, 6, and even 5, as well as CF Builder (and CF Studio!)

For those on CF 9.0.1, it includes the latest CHF1 for CF 9.0.1.

Note that it also lists CHFs for CF 8.0.1, 8.0, and 7.0.2.

As for updaters, it includes those for 9.0.1, 8.0.1, 7.0.2, 7.0.1, 6.1, and so on. (Sadly, there's no HTML anchor within the page for sections like the 9.0.1 updater, so I can't offer a link to that part of the page. But if you're still running CF 9.0, go get it! It includes useful new features.)

As for getting a list of all the individual hotfixes (and CHFs) for any specific releases, there are individual pages for those:

• "ColdFusion 9 : List of Hot fixes"
• "Hot Fixes | Cold Fusion 8 and 8.0.1"
• "ColdFusion hot fixes (MX 7 through MX 7.02)"
• "ColdFusion Hot Fixes (MX through MX 6.1)"

While these list both hotfixes and CHFs, the info on the CHFs should be the same as the main "CF updates" page offered previously. But note that these version-specific update pages may well list new hotfixes that came out after a CHF. Do keep an eye on them.

(You may wish there was a better way to keep up with updates and hotfixes, whether a feed you could follow, or even an automated update mechanism. Sadly, there have been feeds but I'm not aware that is reliably updated by Adobe. And there is no automated update mechanism for CF from Adobe. But there is a free tool and service that solves both those problems, providing an automated update mechanism and constantly updated feed of hotfix notifications. For more information, see Merlin Manager.)

Finally, again, look for another entry to come on the sticky problem of how you can't "just apply the latest CHF" and assume you're good to go on any previous updates for that release. Sadly, it's just not often the case.