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.

It's a simple JVM tweak to cause it to use a fixed port:

-DDEBUGGER_SERVER_PORT=portNumber

You can add this either in the "Java & JVM" page of the CF Admin (if in Standard or Enterprise Server), or on the java.args line in the jvm.config file (for any form of CF).

You do need to restart CF for this to take effect.

A few warnings are in order

First, as always, be very careful when changing the jvm configuration. If you make any mistake, then it's possible CF won't be able to restart. (This is one strong reason to favor making changes in the jvm.config file, rather than the "Java & JVM" admin page. If CF can't start, you won't be able to get to the Admin to undo your changes. By knowing how and where to edit the file, you can undo any bad changes.)

Second, beware that you don't pick a port that's already in use, or again CF won't start. And beware that while it may be open now (if you test it), it may not be open later if something's running then that is not now. Along those lines, ....

If you're using multiple instances...

Third, beware especially if you're using the Multiserver form of CF deployment (multiple instances) where by default you have the multiple instances sharing one jvm.config. In that case, they all would inherit this setting, and whichever instance starts first would claim that designated port, and then the others will not be able to start (reporting an error like "FATAL ERROR in native method: JDWP No transports initialized" or "bind failed: Address already in use").

There are various resources that discuss dealing with how to cause each instance to have its own jvm.config (which is a little more challenging when you run CF as a Windows service). See any of these blog entries:

• Nate Williams
• Mark Kruger
• Jeff Houser
• Scott Stroz

Where is this port tweak documented?

I'm sure some may wonder, "where would I have learned of this DEBUGGER_SERVER_PORT tweak for the debugger port?" It's easy to have missed but it's discussed in several places:

• The CFBuilder docs page on using the debugger, also in the whole user guide in PDF form
• Mentioned also in the cf8 release notes (PDF) (the debugger was in fact enabled then, for use with the Adobe CF Eclipse extensions, and is something I've written about before: see older entries in my debugging category here). Sadly, while the CF8 docs do have a page on using the debugger, the page makes no mention of this port setting argument. Worse, I see now that we can no longer add comments to the help pages in that release, to point to the CF9 docs for more.

Want still more documentation on this and more about the debugger?

I also document it in my 25-page chapter on the CF Debugger in the ColdFusion 9 Web Application Construction Kit, Vol 2. Fortunately, that chapter is one of a few that are available online. If I may say so, it's about the only substantial documentation on the CF debugger, as I cover not only understanding and configuring it, but also troubleshooting like that above. (And the concepts apply just as well to CF8.)

Hope all that helps someone.

Well, there are several ways you can watch them, as this entry will discuss, and some may be better suited to the job than others. It can be very interesting to discover what's going on, especially if you're having any suspected performance problems which you think may be related to ORM processing (or just if you wonder what all it does for you).

As for spying on the SQL, of course ORM support is just a different way that the CFML engine (through the ORM framework) sends SQL to a database via a regular DSN, just like any other request, so there's nothing really "tricky" about this. It's just about realizing that while you don't write the SQL yourself, it's still generated by the CFML engine/ORM framework, and you may not realize/consider the available tools which can spy on it, just like any other DB processing from within CF. Indeed, some people may not even realize how many options exist to spy on JDBC interactions from their CFML engine to the database engine.

The good news is that there are several approaches, some included in CF (some depending on the edition), and some available separately which would work in any edition of CF or the other CFML engines (Open BlueDragon, Railo, etc.), and with any of the ORM frameworks. And again, some may be better than others for certain challenges.

(FWIW, besides the aforementioned Transfer and Reactor, there are still other ORM solutions for CFML, which I mention in my CF411 list as CFML ORM Frameworks. Indeed, note that you can run Hibernate on CF prior to CF9, if you want to.)

Built-in ORM Logging Option

First, note that there is indeed a built-in option in the CF ORM setup where one can enable logging, settable in the application.cfc: see the this.ormsettings option and its available key/value pair, logSQL="true".

There are several resources where you can learn more on that (and a related log4j property file approach to logging this). Besides the CF9 docs page on the ORM settings, there is also a blog entry by Adobe engineer Rupesh Kumar.

The default is to log this information to the console, but you can manipulate those log4j settings to tell it to use a file (see the links above). Even so, this will result in quite a lot of data being logged, which you will then need to connect back to your specific requests. The following approaches may be preferable.

Using FusionReactor or SeeFusion

Users of any CF edition (6+) or CFML engine can use tools like SeeFusion and FusionReactor, which have always had the ability to monitor database interactions by "wrapping" the datasource to be monitored. FusionReactor engineer John Hawksley has posted a recent article specifically on monitoring CF9's ORM interaction, in the FR Devnet site, Using FusionReactor's JDBC Driver Wrapper With ColdFusion 9 ORM. Its concepts would apply to any ORM, of course.

Similarly, I've written generically about FusionReactor's database monitoring feature in What is the FusionReactor datasource monitoring feature? Why would I use it? Powerful stuff. As I point out in that article, the concepts discussed apply as well to SeeFusion's ability to monitor queries by wrapping datasources.

That said, it's worth noting that FusionReactor does have a couple of advantages, in that it provides for the display of all queries for a given request (while viewing the details of that request), whereas SeeFusion only lets you see the slowest query in a given request. FusionReactor also provides a separately available display of all the slowest queries (across all requests). It also logs every query (connecting it to a given request as well), while SeeFusion (Enterprise, at least) can also log the slowest queries to a database.

And note that both of these track any requests coming out of CF, not just those associated with a given request. So if there is ORM SQL that is associated with the startup of CF, that's tracked too. (And for those aware of issues with CF's Client Variables, such DB activity is also tracked, even that done by the hourly purge, which takes place on a background, non-jrpp thread.)

CF Enterprise Server Monitor

Those running CF 8 or 9 (Enterprise only) will find that its available Server Monitor does offer built-in monitoring of the SQL executed against CF datasources, at least, as long as you enable "Start Profiling" (which also enables other features, and overhead, as well). In this way, the Enterprise Server Monitor can monitor database interactivity, including ORM interactions.

Unlike FusionReactor (and like SeeFusion), it focuses only on showing queries that exceed certain limits, and at that it shows them only in a "Slowest Queries" interface, tracking the slowest queries among all requests. The CF Enterprise Server Monitor also has no logging ability at all.

Being able to see every single DB interaction for a given request (or across all requests) may be all the more interesting for discovering/observing what's happening with ORM interactivity.

Another alternative CF feature

Still another little-known feature for spying on JDBC interactions in CF is by way of the JDBC "spy" feature, which does in fact allow logging of all JDBC interactions mde from within CF. This feature was first enabled by way of the DataDirect 3.5 driver update which was made available (as an optional upgrade for 6 and 7) in the CF 7.02 timeframe. I wrote about the Spy feature back back in Aug 2006.

Since then, CF 8 (and now 9) offer it instead as a new "log activity" option in the "advanced settings" for a datasource definition in the CF Admin (which is disabled by default). I pointed this out in another entry from 2007 as one of many easily missed changes for the CF 8 Admin.

This "log activity" output is not as easy to interpret as FusionReactor's logs, and can indeed be voluminous (moreso than FR's), so be careful. Anyway, it's one of the several ways you can monitor JDBC interactions between CFML and your DB engine. Again, any of these may be useful for monitoring any of your CFML/database interactions.

Generic DB Monitoring tools

Indeed, it's worth noting finally that while the focus here has been watching the DB interaction from CF (and the ORM framework) to the database (by watching the JDBC traffic going out of CF and returning), you could just as well watch the DB interactivity from the DB's perspective instead (watching it coming and and being returned).

There are many tools that can monitor database processing, available for each of the major databases (free and commercial). I list several such tools in one of my CF411 section, Database/SQL Monitoring Tools.

Hope all that's helpful, whether you use ORM or not.

Update: David Collie of Adobe has informed us (via comments below) that he has now fixed the two pages with the problems reported here. We thank him so much! Even so, the rest of the information still stands, since some may have suffered the problem of getting the wrong hotfixes while the problem was in place, or even despite his changes, so I'll leave this entry as is to help them.

The problem: you may have applied CHFs for 8.0 by mistake

When checking to confirm if an 8.0.1 server has applied the CF 8.0.1 cumulative hotfixes, make sure that the file in the [cf_root]/lib/updates directory has a jar file name with "801" in its name, like chf8010003.jar. The problem is that it could easily, mistakenly be an 8.0 CHF instead, such as chf8000003.jar (note the "800" reference).

How could that happen? More in a moment. But the problem is that CF wouldn't complain about this (while applying the fix in the CF Admin or if you just dropped it into the lib/updates and restarted CF.) It would just be ignored, and the CHF would not do anything--and you would NOT get the updates you expected in the 8.0.1 CHF.

The root cause of the mistake

So how does this happen? I know at least one source of the confusion. I've complained over and over about this: there's an updates page at the Adobe site which starts out offering a link to the 8.0.1 update (itself). There are no CHFs for it. Rather, the problem is that right after its shown, the page lists the 8.0.0 CHFs! See the screenshot below.

The problem is simply that no one has gone back and updates this page to put the links to the 8.0.1 CHFs. They're just not there.

So many people may easily miss that those are in fact the CHFs for 8.0, not 8.0.1. Worse, since there 3 of them (just as some may know there are 3 for 8.0.1, currently), it's even easier for someone to make this mistake and think they're getting the 8.0.1 CHFs.

Again, since applying them gives no error, I would bet that many are in this situation and don't even realize it (and are not getting the benefits of the hotfixes.) So follow those instructions above and check to ensure that you really do have a jar with 801 in the name (in either [ColdFusion8]\lib\updates in Server mode, or in [JRun4]\servers\[instancename]\cfusion-ear\cfusion-war\WEB-INF\cfusion\lib\updates in Multiserver mode.)

Is the customer to blame for being careless?

Some may sneer that those who make this mistake "get what they deserve", and that it's about "thinning the herd", if people are "so careless". Sorry, I don't agree.

This is a very easy mistake to make, especially for folks who by and large don't spend their days doing this sort of stuff, who might easily assume that what followed the 8.0.1 update on that page was its hotfixes.

And since this "updates" page I pointed to is what's offered on the right of the CF product page, it's just all the more easy to be found--and unfortunate that this problem has been allowed to linger.

So where does one find the 8.0.1 CHFs? and CFH 3?

I wish I could point you to one page that lists links all the the 8.0.1 CHFs, but sadly, that's still another point of annoyance. Some will know that there is this page, ColdFusion Hot Fixes (ColdFusion 8 and later).

But guess what, even IT does not have the CHF 3 listed! :-(

Please, Adobe, fix these things.

You can find CHF 3 for CF 8.01 here.

Anyway, do bookmark that updates page. We can only hope that in the future it will be the place to keep an eye on the latest CHFs for each release of CF going forward.

Who's only now moving to CF 8, you ask?

Some may ask, "why would someone be moving to CF 8 now, which CF9 on the horizon?". Well, a lot of shops don't upgrade immediately, so the question didn't surprise me. So some may only now be moving to 8, and they may not be interested in moving to CF9 for a while. Heck, some (like him) are running only on CF 6, or earlier! Let's just be glad when they people do finally migrate. :-)

And who knows, there may be some who move to CF 9 from 6 or 7, and this info may help them down the road, too.

So, as Casey Kasem used to say, "on with the countdown". :-)

60 page "Migrating Applications to ColdFusion MX 7"

I first pointed out to him that there *was* in fact available in the past an official Macromedia CF document (in the CF7 docs):

Migrating Applications to ColdFusion MX 7 (PDF)

At 60 pages, this is quite a good resource to consider. It "describes migration and known compatibility issues between ColdFusion Server 5 and later versions, including ColdFusion MX 6.1 and ColdFusion MX 7."

Sadly, it was not updated for CF 8, but really, the bigger differences in things were between 6 (being the first release after the rewrite of CF on java) and higher. Of course, those moving from 5 (when CF was written in C++) to higher face far more differences. Again, the guide even covers that. So even those skipping 7 to go to 8 should at least look at the guide.

Never heard of the guide? I'm not surprised. I'll take that up at the end of this entry.

Jim Priest Sought CF8 Migration Stories

Now, he did ask about migration to CF8 specifically.

There was at least one blog entry, from Jim Priest, that sought such CF 8 migration stories.

In the comments, someone commented about "CF8 performance on our CFC-driven apps" after the upgrade to 8. As many now know, that was likely due to a bug in the JVM, rather than CF. CF 8 came running on on JVM 1.6.0_04. Early in the CF8 lifetime, people suggested dropping back to JVM 1.5, but by late 2008 Sun had fixed the problem in 1.6.0_10, and that became the recommendation. Many blogged about it, including Sean Corfield and Ryan Stille who also walks you through making the upgrade.

Someone also commented (in Jim's CF8 Migration Stories entry) about losing their CFIDE directory after the upgrade. I don't know if this is the exact problem, but there was a similar issue documented in the CF 7 timeframe: "CFIDE and cfdocs folders removed after migrating from ColdFusion MX 6.1 to ColdFusion MX 7".

Jim's entry has comments closed for now, so I can only offer these thoughts here. I just asked him by email if he may reopen it to let people post observations like these, to help people who may yet find it and the older comments. We shall see.

Josh Adams offers still more resources

I just found also that Josh Adams (of Adobe) also blogged about Migrating from ColdFusion 5 or older to ColdFusion 8. He shares some other interesting resources, though not that CF7 migration guide. I'll drop him a note and I suspect he'll get that added ASAP. :-)

Steven Erat's discussion of migration from 4.5 to 7

Again, while not specifically about moving to CF 8, Steven Erat did blog some resources to help someone making the move from 4.5 to 7, in his entry, Migrating applications across a six year gap in ColdFusion server implementation. That offers a link to the Migration Guide above but also release notes for each release between 4.5 and 7.02, which is a nice touch.

Don't forget to apply hotfixes

Besides looking at the release notes for each release (something I also highly recommend), I'll also remind folks to also always check for updates, hotfixes, and cumulative hotfixes for any release you may install. What you download (even today from Adobe) may not be the absolute latest version of whatever release you get.

I'll do a blog entry about that with more details in the future. (I did discuss it in my CFMythbusters talk, and the PDF there has some good pointers to get you started on this topic, among others.)

No surprise if you never noticed that CF7 Migration Guide

Sadly, you won't find that CF7 Migration Guide I mentioned on the CF7 livedocs page, since it's a PDF (never made as an HTML file, which the livedocs are). Instead, it's listed on a different CF7 documentation page, that can itself be easily missed. (It is linked to from the CF product and support pages.)

And again the Migration Guide wasn't updated for CF8, so of course it's not mentioned on either the CF8 equivalent of that page or the CF8 livedocs page. Still, since the "changes" from 7 to 8 weren't substantial (new features, not many--if any--breaking changes), the guide helps those moving from CF 5 or 6 to 8, too.

Some won't want to miss the substantial Getting Started Guide

Finally, while we're mentioning CF7 docs that people may have missed, check out also "Getting Started Building ColdFusion MX Applications". That is/was at least listed in the CF7 livedocs (and the other doc link), above. Still, it seems many missed it. It's over 150 pages of great introduction to CF application development (and yes, it shows use of CFCs not just tired old CFQUERY/CFOUTPUT development). Sadly, it too was not upgraded for CF 8 (or 9). It was a great resource for those getting started with CF. I still recommend it all the time.

What other CF 8 Migration resources exist?

So that's my "quick" answer to the person asking for CF8 migration resources. Anyone have more? Whether moving to 8 from 7, or 6, or earlier? :-) Comment here. Readers will be grateful.

I'll prime the pump with a couple more, where people described challenges they faces:

• My ColdFusion 8 Upgrade, by Barney Boisvert
• Upgrading To ColdFusion 8 From ColdFusion MX 7, by Marcelo Lewin

Hope that's helpful. And since I give a nod to Casey Kasem at the opening, I suppose some will think I should mimic his successor, Ryan Seacrest, in closing here. This is "Arehart, out". :-)

I actually did 2 Max talks (in addition to my Unconference talks), and I mentioned the other in a previous entry.

I'll note as well that I list this and all presentations I do, with links to PDFs or recordings, at the presentations section of my site.

Finding other CF Videos at tv.adobe.com

Finally, note that you can find other CF videos by selecting the "all product" category and choosing CF. Of course, you can also use the search field as well to find specific speakers or topics.

I actually did 2 Max talks (in addition to my Unconference talks), and I've mentioned the link to the other in another entry (so as to title and categorize it separately).

I'll note as well that I list this and all presentations I do, with links to PDFs or recordings, at the presentations section of my site.

Different links for Max videos have been shared

Indeed, FWIW, I'll clarify that on that presentations page I previously listed a link to a recording of the talk which was available only to registered Max attendees. Unlike the first link offered above, at tv.adobe.com and open for all to view, this other link was at groups.adobe.com, specifically the Adobe Groups Max NA site, which required a login and you could only join if you were a registered Max attendee.

Sorry if that last part's confusing. It's just a result of Adobe trying different ways to make the content available, which was happening at the same time that the Adobe layoffs were happening.

Let's just thank them for providing the videos at all, and especially for all the free ones at tv.adobe.com.

Finding other CF Videos at tv.adobe.com

Finally, note that you can find other CF videos by selecting the "all product" category and choosing CF. Of course, you can also use the search field as well to find specific speakers or topics.

Here's a screenshot of what you may see:

Note that this is not an error related to logging in. You do need to fill in a username to log into the Server Monitor, even if CF is set to only ask for a password when logging into the Admin. Just use "admin". This and other facets about the CF8 Server Monitor are covered in a 4-part series of articles I did in the Adobe Dev Center, starting here.

Confirming this is the cause of your Monitor challenge

From my observation, this error is related to a problem with the Flex client being able to talk to the server using a URL it needs to use, and the problem is web server related.

You can confirm if what I'm about to describe is your issue by trying to access the URL that the server monitor tries to use to access the Flex Gateway for CF, such as:

http://localhost/flex2gateway/

Actually, you should use whatever domain name/port you're using to access your CF Admin, which is then used when you ask it to open the CF8 monitor, which may be a URL like this:

http://yourserver/CFIDE/administrator/monitor/launch-monitor.cfm

Anyway, if that test attempt to open the /flex2gateway/ url comes back with a "file not found" (or 404) error, as opposed to a blank page, then you likely have the problem I'm describing, whereby your web server is mistakenly looking to verify that a file exists for the path you're specifying. You have 2 solutions.

First, let me note that this flex2gateway URL is not a file, nor a directory. It's a value intercepted by a servlet filter defined within CF. You need to tell your web server not to check for any existing file (it's trying to use one of the "default documents" that are used when only a path to the web server is provided.) Before launching into how to fix your web server, you may want to consider one other possibly simpler alternative.

Changing to use the Internal Web Server

Some will note that I've used no port above in the URL. That's why I point out for you to try whatever URL is used to access your Admin. In the case above (and the people who have reported this problem so far that I've seen, they've been trying to access the CF admin using their external web server, IIS.

If instead you were to use the CF internal web server to access the CF Admin, you'd have a port in the URL, like this:

http://yourserver:8500/CFIDE/administrator/monitor/launch-monitor.cfm

(or it could be 8300, or 8301: whatever is the port for accessing the built-in web server for CF, if you chose to implement that when CF was installed, and you are accessing the Admin that way.)

Well, I'd propose that if you DO use the internal web server, you probably won't get this error at all. The problem seems related to using IIS to access the Admin (and the CF 8 Server Monitor).

That said, I'll suggest that one quick solution folks can try is to see if indeed they can access their CF Admin (and monitor) using the internal web server. (If you can't or won't use it, I have the solution for getting it to work with IIS, in a moment.)

You just need to know what port to use to access the internal web server, if it's enabled.

First, you may find that if (on Windows) you use Start>Programs>Adobe>ColdFusion 8>Administrator that it will open using the built-in web server. If it does, see if using that gets you around this whole problem.

If that opens it with external web server (doesn't use a port like those above), or if you aren't on Windows and have no Start menu, you can also get the web server port (and indeed enabled it, if disabled) by way of the jrun.xml file. Rather than detail it here, I'll point you to a couple of resources:

Configuring the Macromedia ColdFusion MX built-in web server is an old technote, but the info still applies. Where it talks about disabling the internal web server, you'd want to reverse that, of course. There can be more subtleties and challenges to running the CF admin on the internal web server, if you don't configure it that way at the start, such as where are the /CFIDE files? Are they in the [cf]/wwwroot? or in your web server doc root, like inetpub/wwwroot? The built-in web server will look for them in the [cf]/wwwroot, so you may need to copy the CFIDE into this directory, or add a mapping to the built-in web server to point to the path as being located externally.

Making the change in IIS

Or you could just fix IIS to let you access the server monitor via IIS. The problem may be due to a setting in IIS (verify that files exist) that you may have caused to be set. (I don't know if it's set by default when CF is configured to integrate with a site, but I wouldn't think it was, so maybe this affects those who add new sites or configure things manually.)

And since this problem may affect other Flash/Flex apps trying to talk to CF, it may be worth doing for all such users. But this does come with a caveat to be aware of, if you might be using NTLM security to control access to files requested via IIS. More in a moment.

I offer the solution for IIS 6 and 7. I don't know if the same problem can affect Apache. If so, and anyone can offer the solution for there, please do comment.

Making the change in IIS 6

For IIS 6, launch the IIS Manager and select the web site which has the CF Admin you're trying to use. (It may be that you've also configured IIS so that ALL web sites are configured for CF, in which case this setting would be not at the site-level but at the root server-level, so you'd select the server name instead in the left IIS pane.)

From there, right-click and choose properties, and then select the "home directory" tab, then in the "application settings" area click the "configuration" button, and in the "wildcard mappings" section you should see something like "C:\ColdFusion8\runtime\lib\wsconfig\1\jrun_iis6_wildcard.dll" (which will be different, of course, for the JRun4-based Multiserver deployment).

This value is implemented here during the install of CF if you tell it to integrate with IIS, or by your running the CF Web Server Configuration tool after the fact.

Select it, and choose Edit, and if the "Verify that file exists" option is checked, un-check it. This setting can be confusing: you may think it means "verify that the named executable exists", but it doesn't. It refers to whether files requested and passed through this handler should be checked to confirm if THEY exist. Here's a depiction of the setting and how to get there.

Now try the URL above, and it should no longer give a 404. Then try again to login into the Admin. (Actually, you may find that you can just click the "cancel" button and it will login, even if the values for username and password are blank. I find this helpful when the CF server is temporarily unresponsive too, and the Monitor login screen pops up.) Hopefully the server monitor now works for you.

Note that this was NOT about changing the handler mapping for .cfm files, which also offers an option to control the "verify that file exists".

A caveat about access via IIS to NTLM secured files, and another alternative

Thanks to Mike Gillespie for the following notice and clarification. If you use NTLM security (windows integrated authentication in IIS) to secure files accessed via IIS, then you DO NOT WANT TO make the above change for your IIS site. I share below what he offered to me.

But I'd point out again that even with that issue, you could still use the built-in web server is a solution. Or, sticking with IIS, you could also create a new IIS site just for accessing the CF admin and monitor, and make the change above for that site only.

Anyway, if you do use NTLM security to control access to sites requested via IIS, consider the following:

The check that file exists option is required if you want to use NTLM perms to secure .cfm files. http://www.adobe.com/go/tn_18516 (Steps 1-4)

If you have a secure folder on your webserver put a .htm file and a .cfm file in it. Do not give your ID access to that folder. In IIS turn on clear text and NTLM auth.

With the "check that File Exists" option unchecked, try this test.

Try to access the .htm file in the browser - access denied

Try to access the .cfm file in the folder, - access GRANTED - so much for NTLM perms

Now check the box and try again (you will need to recycle cf and IIS)

Try to access the .htm file in the browser - access denied

Try to access the .cfm file in the folder, - access denied as it should be - but flash forms and server monitor are dead.

So "fixing" the Server Monitor problem on an authenticated server just broke the security of the server for the sake of monitoring... [frown>]

In a nutshell.

If you implement this so that CF pages can be authenticated against Windows Security http://www.adobe.com/go/tn_18516, then Flash forms break (and the server monitor too). So to get flash forms (and the server monitor) working, you have to implement this, which fixes flash forms (though every user gets their own personal file on disk on the server that has to be cleaned up) but it does not fix the server monitor.

It is the "check that file exists" selection that breaks the Server Monitor (and flash forms).

On a cf webserver that grants anonymous access there is no reason to check the "check that file exists" box. However, on a server that does authenticate users for NTLM file access, that box should be checked.

This section above was added after the entry was first posted.

The change for IIS 7. None needed?

For IIS 7, it's a little different. I actually run IIS 7 (Vista) and am not sure how/where the wildcard mapping equivalent got created (I may have fudged it manually), but it's now listed as a "Handler Mapping" (in the properties for a web site). In my case, it's labeled "AboMapperCustom-32635", but just look at those listed as handling "*" meaning all requests. It's listed with a value of IsapiModule in the Handler column. (If you're looking at a specific site, and the "Entry type" column says "Inherited", then there is another mapping at the server level, so select your server name in the left IIS panel, and repeat.)

Even so, I see no option to control "verify that file exists", so maybe this problem can't happen in IIS 7. I will say, FWIW, that there is indeed a an equivalent to that "verify that file exists" option, at least for specific extension handler mappings. Look a the one for .cfm, for instance. Double-click it to see its properties, and note a new button called "request restrictions". It has an option, "Invoke handler only if request is mapped to", and an option of "file". Again, though, this does not affect requests to non-cfm requests like that for the /flex2gateway/ URL.

About other Flex/Flash apps

As I said, it may be that the info above will help other Flex apps having trouble talking to CF (the CF8 monitor is a Flex app), but I'll note that this problem doesn't affect all Flex apps: only those that connect to CF via IIS.

For instance, on this same server where this problem occurred, there was never any problem using FusionReactor (which is also a Flex app). It was working fine the whole time. But then its default behavior is also to use its own Built-in web server, so requests weren't going through IIS. If I did try to use IIS to access FusionReactor, then it too failed (with a file not found), and the fix above solved that.

I did a little digging, and hadn't seen anyone else write about these (it seems) in the CF blogopshere, so I'll share what I found. They're nothing dramatic.

Autonomy=Verity

In the first case, I guess I just missed the news, but back in 2005, Autonomy acquired Verity. (Seems like the acquisition last month of MySQL by Sun. Doesn't appear to have been too significant in the grand scheme. The tools continue to be known by their former company names.) Also, more digging found that this had been mentioned in the 8.0 release notes as well, but I just hadn't noticed it. FWIW, there was no mention in the CF7 notes/docs that I could see.

TVirtualStringTree in Report Builder?

What about TVirtualStringTree? Well, that isn't as obvious. It appears to be a Delphi component, and the only thing I can think of that's written in Delphi that might have been updated for 8.01 would be the CF Report Builder. Perhaps Dean Harmon or someone else from Adobe can confirm that guess. It's not important, of course.

Just one of those "things that make you go hmm" (to the younger folks out there, that's a reference to a bit from the old Arsenio Hall show of the early 90s. Gosh, now I know how my parents must have felt when they'd talk to me about the the Jack Parr show, when I was a teen in the 70's!)

PS: Searching the CF blogs

BTW, I said I hadn't seen any mention of this in the CF blogosphere. Was I going only on my memory? Heavens, no. I don't at all claim to have read most (or even 10%) of all many, MANY blogs out there on CF. It's great that there are so many, and that we have so many CF blog aggregators. But even then, none let you search all the past blog entries (at least it seems to me, as I searched for some text on that entry in all the aggregators and none found it).

So how does one do a quick search of most CF blogs? Well, last year I created a Google Custom Search Engine I call CFSearch. It lets me (and you)search only CF-related blogs and other resources. There are other CF CSEs out there, and I wrote about them back when I created mine.

I make a bookmark link for my CSE so that I can do such a search easily. Hope you'll consider doing the same.