I offer in this post a solution to a problem that I and others experienced regarding the latest CF update (released Dec 10, 2025 for ColdFusion 2025, 2023, and 2021, which I just blogged about separately).

We only experienced it with CF2023, but others have reported the problem in the past, with various CF updates to any CF version. As I'll explain it seems to be a caching problem relative to Adobe's servers (so some people may experience it, but not others):

• First, you may find that after applying the update all the of the packages that were to be updated by the release will instead be UNINSTALLED unexpectedly/
• Even worse, that could mean that the administrator package is uninstalled, such that you can't get to the CF Admin after the update...which will also mean you can't use the admin to try to "uninstall the update" (if you wanted to).

Of course, you could go the command line route, as you would be told to consider doing if the Administrator package was uninstalled, using CF's cfpm tool to either install the admin package or even perhaps try to uninstall the update entirely.

But I have what seems to be a better solution. It's quite simple, but bear with me while I explain it...both to help you (and Adobe) better understand what seems amiss, and in case more info may come out soon from them or other folks.

Beware also that if you may have "solved the problem" yourself, consider what I have to say below--you should confirm that you DO in fact have the correctly UPDATED packages, which you may have installed using that cfpm tool.

[....Continue Reading....]

I'm delighted to announce that I've been selected to speak at the upcoming Into the Box event (in DC in early May), where I'll be presenting "Hidden Gems in FusionReactor: for BoxLang, ACF, and Lucee Users".

This should not be confused of course with the "Hidden Gems in CF2025" talk which I also just announced that I'd be presenting at the upcoming CF Summit East (next week in DC) and CFCamp (in Munich in late May). It'll be a busy few weeks! :-)

As with them, it's always a thrill to attend this annual event. Following is the topic description and more.

[....Continue Reading....]

If you've recently applied CF2021 update 15 or are planning to, you need to be aware of a known issue which can cause unexpected removal of some CF packages (modules) which occurs upon the CF restart after installing the update: specifically it's the document, htmltopdf, pdf, presentation, print, and report modules. The good news is that these are easily added back, either using the CF Admin or via the cfpm command-line tool (added in CF2021).

In this post, I discuss this issue, those options for adding them back, and I also share how I'd found the underlying root cause of the problem: the update has a mistaken internal indication that these packages were updated in this update, when they were not. I'm hoping that Adobe may soon be fixing the problem by creating a new update file, to at least benefit those doing this update going forward. I'll share also the bug report for that (and another on a related matter, about installing multiple packages via cfpm).

TLDR

If you just want to "solve the problem" caused in applying this update 15, simply go into the CF Admin and its "Package Manager" page, go to its "Available Packages" section, and click each of those to install them. (Couldn't you also click the "Install All" button offered there? Yes, but there are reasons to be careful about that. Couldn't you use the cfpm tool? Again, yes. I will address both these points and more, below.)

[....Continue Reading....]

Don't miss that Adobe had added a useful feature (a "patch", made available in Apr 2024) to help in identifying any CFML code you may have which refers "implicitly" to scopes that would no longer searched (for any variables without a scope prefix), which is the new default behavior for CF2021, CF2023 and beyond as of the March 2024 updates (updates 13 and 7, respectively).

TLDR; (more on each of these points, in the rest of this post)

• For more on the update and the change regarding searchimplicitscopes, see my blog post on the March update
• By following the simple couple of steps (including downloading a needed "patch" as discussed and linked to below), CF will start logging (to a new unscoped.log) whenever code is run that would access an unscoped variable when that would cause CF to implicitly search through scopes (external to the request) which it would no longer search if "searchimplicitscopes" was false. (To be clear, the new logging only works if searchimplicitscopes is true, otherwise such searching would fail if searchimplicitscopes is false, as is the new default as of the March 2024 updates)
• The "patch" is a jar which you must manually obtain and put into place--it is NOT included with the March 2024 CF update, or any others. The steps are very simple, discussed below or in an Adobe technote that was released in the weeks after the March updates, with the title: View unscoped variables in a log file
• Note that this patch is also NOT included in the June 2024 CF updates, CF2021 update 14 and CF2023 update 8
• Further, beware that if you DO apply any update to CF after applying this patch, that update will REMOVE this "patch" (and any jars in the lib/updates folder which is referred to in the technote). Therefore, you would need to put the jar BACK in manually after any such CF update, for it to continue doing its logging
• Finally, FWIW, note that you can even leverage this patch in the CF two updates PRIOR to the March 2024 updates which introduced the change in the default for searchimplicitscopes, so updates 5/6 and 11/12, respectively. That means someone could also use this patch to test BEFORE moving to either the March 2024 updates or later

Again, more on each of these points below. But for some, the news and the link to the technote (and my couple of tips above) may be all they feel they need to hear. For others, I think more perspective may help, so read on for that.

[....Continue Reading....]

This is important news for those using CF's feature to store sessions (session variables for all sessions) in Redis.

Some folks, using it with CF2021 or 2023 found CF was somehow heavily impacting their Redis instance. The good news is that I've found an easy fix/workaround (until Adobe fixes it formally).

For more (including why you may or may NOT be impacted by the issue), read on.

[....Continue Reading....]

I'm delighted to announce that I've been selected to speak at Into the Box 2024, in DC, coming up in May. This will be my 5th time presenting at this wonderful event, going back to my first time in 2017.

My talk will be...

[....Continue Reading....]

Note: This blog post is from 2023. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Here's something new to beware, a change in the most recent Oracle JDK installers for Java 11 or 17 (since Jan 2023) which could break your apps which rely on Java, whether on Windows, macOS, or via RPM, where the new Oracle jdk installer works quite differently, pretty much without warning, which may be confusing or could cause real trouble for those caught unaware, as I try to explain in this post.

TLDR; If you run the Oracle JDK installer for Java 11 or 17 after updates 11.0.18 or 17.0.6 or later (on any OS), it has two new behaviors:

1. it will remove any prior update installed with the installer that major version, and it may or may not tell you that it does it (and any app relying on that old version/configured to use it specifically may not be able to restart/start)
2. it will create a new folder to hold the new JVM with a name that only reflects the MAJOR version, like jdk-11, whereas previously the foldername also reflected the minor version, like jdk-11.0.17. You must change any app configured specifically to use such a specific Java version to use this new folder. Or you can instead manually extract the new JDK from the zip or tar.gz and place it where you like, configuring your app to point to that (some folks have always done this. This post is for those who have instead always used the installer.)

To be clear I'm referring here to new behavior in the JDK installers from the Jan 2023 update, which I blogged about the day they came out. This topic will apply also to subsequent JVM updates as they come out in the future. (Fortunately for some, this issue does NOT affect those running Java 8 or below--though I learned in Apr 2024 IT DID change also for Java 8 installers since July 2023. See more below. And this aspect of it being a "change in behavior" will not affect Java 19 or above, as I explain later.)

While the technotes for the new updates (which I point to in my post above) DO make mention of the issue I'm describing, I don't feel they do it in as obvious a manner as they might (it's not clear how it affects CURRENTLY installed earlier updates of JDK 11 or 17), and I've already helped some people dealing with the ramifications of the change. And of course it's all the MORE important to make sure this is made known to those who might NOT read the release notes.

I've also found that the JDK installer doesn't ALWAYS warn that there are running processes using the older JDK version that it's about to remove. And to be clear, it won't warn about applications that are NOT running but which are configured to try to use the older JDK version that would be removed.

Read on for:

• The issue, in brief: JDK installers now implement a single-minor-version-per-major-version policy, deleting older JDK installations
• The implications of this changed behavior which may trip you up--and a seeming solution
• Yet another solution: use the JDK zip install approach instead
• Some closing considerations

Before going further, it may help to clarify that when I (or others) refer to a "major Java version", we are referring for example to Java 11 or 17 (or Java 8 or 19, and so on). And when we refer to a "minor" version, we mean an update to such a major version, such as 11.0.17 for Java 11. Previous JDK installers did allow us to run more than one minor version of a given major version, which could be an advantage. Newer ones no longer will.

(After I posted this, I heard some people assert that "this is not new behavior: Java's always popped up and offered to remove old versions". Those folks are misunderstanding something: that was true of past JRE installers (like in Java 8 and earlier, which don't exist for Java 11), but it was never the case for Oracle JDK installers (even for Java 8, before Jul 2023). THAT's what's new about the JDK 11 and 17 installers as of Jan 2023, but it may surprise those who never saw a JDK installer do that, thus this post.)

The issue, in brief: JDK installers now implement a single minor version per major version, deleting older minor versions

In brief, the new behavior is that:

• The new Oracle jdk installers for 11 and 17 now implement a single-minor-version-per-major-version policy, supporting only ONE minor version (update) being implemented at a time by that installer, for a given major version of Java 11 or 17
• As such, the new JDK installer will attempt to REMOVE all previous minor versions/updates to that major Java version, which were installed by previously run jdk installers for that major version. (To be clear, it will NOT touch any Java that was implemented by you or some software, which put Java someplace the JDK installer doesn't know about)
• The problem is that you may or may not expect that removal of the old version to happen (it's new behavior for Oracle JDK 11 and 17), and it may have a serious impact on existing apps that may be currently using or set to use such an earlier minor version--which this process would try to remove--and of course it may not be able to, if it's in use!
• And even if you let this and future JDK installers create such a generic folder, and you point your app at that, again if a future update tries to run and wants to update that folder, it will NOT be able to do that if your application is RUNNING and pointing to that folder.

Let's make things more clear: say you already have in place two "minor" versions of the "major" version of Java 11, for example 11.0.16 and 11.0.11, which were implemented by the previous JDK installers for those versions. Upon running the Oracle JDK installer for the new 11.0.18 version (or future later versions), that new JDK installer will attempt to REMOVE BOTH those 11.0.16 and 11.0.11 installations first!

Again the same is true of the Java 17 jdk installer.

(As for Java 8 or below, Oracle did not opt to implement this change in Jan 2023. That has changed as of Jul 2023,as I learned in a helpful comment below from Eric on Apr 18 2024. See also my reply to him for still more. As for Java versions 19 and above, it ALREADY implements this change from its original version, released in Sep 2022.)

The implications of this changed behavior which may trip you up--and a seeming solution

There are a couple of VERY important implications of this change in behavior or the Oracle JDK installer, including some things that may surprise you--and one that may really trip you up, with a solution I can offer:

• The most important implication of course is that you may NOT expect the JDK installer to DO this removal of the older version/s at all. Now you've been warned
• And you may well be warned by the new JDK installer about this, telling you that some running app is using an older JDK update to be removed, at least giving you a chance to realize what's happening--and you can even cancel the install if you want.
  • Even so, the way the installer reports "already running processes" may surprise you: it will report processes by process id. It will be up to you to use your OS tools to find what process each of those points to, so you can stop them. (And I was surprised on one machine that it listed over a dozen processes, even ones that did not involve Java.) Fortunately, the JDK installer offers a "retry" option, so you can check if it feels you've stopped enough processes. I did not have to stop ALL of those listed, after all.
• Then again, you may have some application that's configured to use such an old JDK--but if that application is not running, then obviously you can't expect the installer to warn you about that, since it's looking for whether any currently running processes refer to it. That's bad enough.
  • But on 2 of 3 machines I tested on, where I DID have running processes that were using that JDK to be uninstalled, the new JDK installer did NOT offer me that warning about running processes using it. It just deleted it.
• And the sinister problem about those last two points is that you (or colleagues) may not realize what's happened until hours or even DAYS AFTER the new JDK installer was run, deleting the prior ones, so your apps that were relying on the older JDK (which is now REMOVED) will simply not start the next time you try to run (or restart) them. And it's very likely no one experiencing THAT problem will connect the dots to this having been caused by the new JDK installation.

Fortunately, solving those last couple of problems is rather easy it would seem, once you understand that this is what happened.

A seeming solution, with a caveat

The seeming solution would be to just change your app to refer to the NEW JVM location. That would seem such great news: with the new approach, there will always be only ONE JDK location for a given major version. On Windows, for instance, it will by default be C:\Program Files\Java\jdk-11, without any minor version number. Of course, in some apps it's your responsibility to escape those Windows slashes, as in C:\\Program Files\\Java\\jdk-11.

There is a caveat, though: this is STILL a problem if you have an app running--pointing to that new generic folder--when you later perform the NEXT JVM update. If that app is running (which could be an app server or could even be an IDE), then when that next JVM update wants to write the new version's files into that generic update folder, it WON'T be able to. With this new installer approach, it's now incumbent on you to remember to STOP whatever app points to that generic jdk version folder. If you don't, the update may fail reporting that it couldn't work--but I've seen if NOT fail and just fail to completely install the jdk update! :-(

Yet another solution: use the JDK zip install approach instead

So what are we to do, if we don't want to have to be so careful? Well, here's more good news.

When each JVM update comes out, there is offered not only such an "installer" as is discussed here, but there is ALSO the offer of a zip (or tar) implementation of the JVM. You simply extract that into a folder (wherever you want), and defaults to creating a folder whose name holds the current update version number.

In using this zip approach, there's NO chance that you "have an app running pointing to the folder that will hold the updated java", because that new version wouldn't yet have existed. :-)

You simply need to change your app to point to the new JVM's location. That's a tradeoff that I think many would find preferable over the risks discussed above. To each their own.

Finally, as for HOW to change your app to use WHATEVER JDK location you would want to use, there are so many ways to control that depending on your Java-based app as well as how it was installed, etc. I'm writing this post in a way that the information will make sense regardless of what Java app you may run. And since someone in your org already had to know to change your app to point to the OLD JDK location (the one deleted), I'll have to leave this as an exercise for the reader. (For my traditional audience of CF users, see my CF Update page with more for you.)

Again, my goal here has been to make you AWARE of the issue, so you can plan for and anticipate it.

Some closing considerations

Before wrapping up, there are just a couple of closing topics related to the above someone may wonder:

• "You say this change of behavior was documented?": Yes. In the release notes for 11.0.18 and for 17.0.6, notice that each has 3 sections with different names ("Disable Side-by-Side Installations of Multiple JDK Updates in Windows JDK Installers", "All JDK Update Releases Are Installed Into the Same Directory on macOS", and "RPM JDK Installer Changes"), which cover essentially this one issue, each with slightly different details.
• "Can't we just re-install the older JDK, if we want it back?": The answer is "yes", in that I was able to do that with the Windows 11.0.17 JDK, for instance. But note first that the next time you run any JDK installer from Jan 2023 or later, that will again remove it. Note also that the aforementioned release notes imply that future installers will PREVENT older JDK installers from running (perhaps only those from Jan 2023, forward.)
• "What about openjdk and other non-Oracle Java implementations?": As I've indicated throughout this post, I'm talking about the Oracle JDK. Some alternative Java implementations ALREADY take this single-minor-version-per-major-version approach, such as the Azul Zulu JDK installer, as I confirmed with their JDK installer and docs for the JDK 11 version prior to this one, 11.0.17.
• "You mention RPM installers. What about .deb files?": While the release notes refer to .rpm files, they make no mention of .deb files--though those are indeed offered as another Linux installer choice, for Debian/Ubuntu. I can confirm that when I ran the older 11.0.17 JDK installer as a .deb file, it installed into a single /usr/lib/jvm/jdk-11/ folder, reflecting the single-minor-version-per-major-version policy being already implemented BEFORE this 11.0.18 update.
• "Does this affect Oracle JRE installers?": Oracle no longer offers separate JRE installers since Java 8. And as I noted earlier, this matter applies only to JDK 11 and 17 installers.

Conclusion

While this new behavior is challenging (all the more because it's new to the Oracle JDK), in time people will come to understand it and deal with it. Until then, I offer all this to help folks and give a heads-up.

If you may feel stuck, I can probably help quickly via my short-term, remote consulting.

As for all the above, I certainly welcome feedback.

Note: This blog post is from 2022. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

In a post today on his blog, Ben Nadel did an experiment "Looking At The Performance Overhead Of A Read-Only Lock". (He happened to do it in Lucee, but the concept applies equally to CF.)

And I wanted to offer some additional thoughts--first planning to offer them as a comment--because there's a lot behind the question and his observations. But as it got longer, I realized it was too long for a comment. Also, I didn't want people to think (in reading a comment on Ben's blog) that I was challenging Ben or questioning his understanding of the matter! Not at all. :-) Instead, I was just wanting to add more context, to help other readers, and based on my years of observing the community.

What I offer here is pretty much exactly what I wrote, but I have added headings, to help readers here:

[....Continue Reading....]

Note: This blog post is from 2020. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

Updated, Feb 2022

This question, "How can I keep CF Admin settings in sync between multiple servers or instances?" was asked today on the Adobe CF forums. The person had CF instances on multiple servers and lamented having to login to each CF admin to make changes that would apply equally to all instances, in particular creating or changing datasources.

They wondered if in fact there was a feature in the CF Admin to "cluster" datasource definitions, like there is (since CF2016 Enterprise) the feature to "cluster" scheduled tasks.

While I explained that there was not such a "feature" to sync CF admin settings generally across instances, I added that there WERE at least a couple of options one could consider using to achieve the goal. (And as an update after I wrote this in Apr 2020, note that CF2021 came out a few months later offering still one more.) My answer elaborating things (as is my wont) was long enough that I should have probably created a blog post instead. After submitting it, I decided to do just that, here (and I have tweaked here what I said, with some more elaboration and links).

Short answer: there are different tools that might be considered to help with this task (especially automating it), and a couple more that some may consider:

• the CFConfig tool within CommandBox, a powerful and automatable command line tool which uses json files and could allow you to sync things, even across CF versions and between CF and Lucee
• the CF2021 cfsetup tool, a new command line tool which also uses json files and could allow you to sync things, for CF2021 and even earlier version
• the CF Admin API (minimalist and manual), which you'd have to code to sync settings or set them in a synced manner
• the CF CAR file feature deserves a mention also, though its use can't be automated (it seems)
• I would advise AGAINST the seeming "shortcut" of copying neo xml files, especially between different servers or CF versions (same with using symlinks, etc.)

For more on all this, read on.

[....Continue Reading....]

Note: This blog post is from 2020. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.

This is a critical warning to anyone who may apply the recent CF2018 Update 8 or CF2016 Update 14, released Tuesday of this week (on Mar 20, 2020). And readers in the future should note it will apply if and as you may update CF from any update BEFORE this one to any update AFTER this one.

To be clear, I do not mean with this warning to suggest that you should NOT apply the update! It implements an important security fix.

Instead, it's that after applying it, your CF web sites served via IIS or Apache WILL likely break initially, until you take one at least and perhaps two extra steps. The good news is that these steps are both easy and documented by Adobe in the update technotes, but they do require that someone do them, if needed. Let me explain.

[Update: I did an abbreviated version of this post on the Adobe CF portal: Three reasons your sites may break, and how to fix them, after applying March 2020 update to CF2018 or 2016. Note I also titled it differently. Just trying many ways to get people's attention. That post may interest some, either to read first (but my TLDR below also tries to abbreviate things also), or especially if you may prefer to give others a link to a post on this matter that is not as "dense" as this one. :-) I do point to this post from there, of course, for the many additional details that some may appreciate.]

Sadly, because many people don't bother to read the CF update technotes (linked to below), and they just apply the CF updates, they are not noticing this issue until they or their users start screaming because their sites are down. There's also a fair bit of "screaming" in the CF community, and folks responding may not know the info that I (or Adobe) have shared, to get things "working again", so I hope this helps bring some calm, and most important the clear solution/s needed.

[....Continue Reading....]