[Looking for Charlie's main web site?]

Finding default/initial CF admin config (neo-*.xml) files, now at cfmlrepo.com

Have you ever wished to obtain a copy of one CF's neo-*.xml files (like neo-cron.xml), for the purpose of setting yours back to its defaults? Folks sometimes need to do that to recover from certain problems.

I've seen the problem raised often enough that when I saw someone raising it this weekend, I decided to solve it by creating a new folder in the cfmlrepo.com site, at least for CF2021 and CF2018 (for now), offering there the initial versions of all the neo-*.xml files for those two editions.

For more information, see what I shared (including more background on the issue, where I got the files, where I put the files, and more) in my reply about all this to the CF Community thread where the user raised the need this weekend.

And for the sake of those who may "just want the files" without any need of explanation or warnings:

I welcome thoughts, feedback, or suggestions.

Lots more to the current CF2021, 2018 prerelease than folks may realize

Have you checked out the many things coming in the updates for CF2021 and 2018 in prerelease the past few weeks? Anyone is welcome to join the prerelease, logging in with an Adobe account. It's a lot more substantial than I think most realize.

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

Pulling Adobe Docker CF images, via Dockerhub or Amazon ECR

Here's some good news for those interested in using the Adobe CF Docker images: it turns out you are NOT required to do the clunky "download/docker load" dance that had been announced in this Adobe blog post on Apr 30, the day before the announced closure date of the previous registry they used, Bintray. There are three other alternatives to do a traditional docker pull, which I didn't know about and I suspect others may not either:
  • First, you can now pull images from Amazon Elastic Container Registry (ECR), including both the CF2021 image and 2018, as well as the add-on and PMT images for CF2021. These are official Adobe images, to be clear. A simple example--that works today--and will give you the CF2021 update 1 image is the following:
    docker pull public.ecr.aws/adobe/coldfusion:latest
  • Second, you can now also get Adobe CF images from Dockerhub, at least as of Sept 2021. Update: When I first wrote this in June, there was still no dockerhub repo. That changed in July when the CF Dockerhub repo was created, and now as of this update on 9/13/2021, you can get the 2021 update 1 image using:
    docker pull adobecoldfusion/coldfusion:latest
  • Update: As of a check July 6. 2021, the bintray repo is indeed no longer available. That said, you can still use the images you may have pulled, even using the eaps.bintray.com/coldfusion repo name prefix before the image names. It's only pull requests that will fail. Going forward, use the other options above. Here's what I had written back on June 17: Finally, despite what the Adobe and Bintray sites said about the May 1 "closure" of bintray, saying that images would be inaccessible after that date, Docker images at Bintray DO remain available for now. This includes CF2021 update 1, CF2018 update 11, CF2016 update 17, and more, so existing docker pulls against those do still work, at least as I write today, June 17 2021

Both the first two were mentioned in a comment yesterday on the Adobe CF forums. And I discovered how the continued Bintray image availability while writing up this post to share the news about those other two!

For more information, including additional background on this transition, more on using the ECR images, and still more links to resources discussing these things, including docs on using the Adobe CF images that many never seem to notice, read on. (I also did an "in brief" version of this post on the Adobe CF portal, where I share the "least you need to know" above. Again, for the rest which should be interesting stuff for many, read on.)

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

My upcoming talk, "ColdFusion at 25: not the kid most have stuck in their minds"

As you may have heard by now, the free Adobe CF Developer Week 2021 will be held June 22-24. My session will be on June 22 at 4p Central in Track 2. While currently the DevWeek site only offers session titles and speakers (descriptions were added after I posted this: click the + sign to the right of each talk), here is mine, from the "presentations" page here on my site:

ColdFusion at 25: not the kid most have stuck in their minds

As ColdFusion turns 26 next month, many seem stuck remembering it only as the "teen" they knew or even the "child", when instead it's grown up to be a capable "adult", impressive in many ways, and even more so recently. In this session, we'll look back at how CF has indeed evolved into a very capable platform, with quite modern features that seem to surprise many--including people working with it currently. If you struggle "finding CF people" or "getting buy-in", perhaps these observations could help you with both challenges. If nothing else, they're things designed simply to help you get your job done, while keeping up with modern practices.

We'll start with many modern coding techniques--which will be familiar to those using more "modern" languages but that many don't realize CF supports, and may have for years. We'll then look at ways that things such as CF installation/deployment, configuration/administration, monitoring, security, and more have improved over the years. And we'll look not only at CF itself but the community surrounding it, ranging from resources for help and learning to tools and services that others have created, making CF a far more complete ecosystem than most give it credit. Put another way: it's not your father's CF!

I look forward to presenting this topic and hope you'll come check it out.

New updates released for Java 8 and 11, April 20 2021

For those using the Long-term support (LTS) versions of Oracle Java, 8 and 11, please note that there were new updates released last week (Apr 20), specifically Java 11.0.11 and 8.0_291. For more on each, see the:

For some, that's all they need to hear. For others, read on.

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

Confirming ColdFusion's Java version via CFML code

Have you ever wished you could confirm with 100% certainty what Java version is in use by the CF instance you are running? Or where the JVM's location is (in case you are told to modify files related to it)?

Some good news is that ColdFusion offers simple ways/variables that can show you each of these, via CFML code. In this post, I share that. I share first a simple single variable which works in CF2018 and above, then I offer a variation for those on CF2016 and earlier, as well as variations for Lucee.

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

Be aware that updates to ColdFusion 2016 will end Feb 2021

Are you still running ColdFusion 2016? Did you know that its "core" support (meaning, public updates from Adobe) will end in just a couple of months, Feb 21 2021? Same for CFBuilder 2016.

The recent release of CF2021 is a great sign for the continued vitality of CF, but this looming deadline is a reminder that as the years roll on, we not only get new versions but we say good-bye to old ones.

Wondering what you can do? or when CF2018 or CF2021 support ends? And what's the difference between "core" and paid Adobe support plans? For more on these, as well as official Adobe documentation that discusses such things, read on.

[Update: CF2016 users got a "reprieve" of sorts, when Adobe released updates to CF2021 and 2018 in March 2021, and they also offered the final update to CF2016, update 17, especially because it address a security vulnerability. Sadly, some of the changes in the update--not related to the security fix--were "breaking" changes. For more on that update, see the Adobe blog post from March 2021.)

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

Why should one be careful about securing ColdFusion ARchive (CAR) files?

You may hear (starting today) about a new admonition (a "strong recommendation") from Adobe that one should be careful to "delete CAR files once they are used". What's that about? And why is it a concern? (And is it ever NOT a concern?) Indeed why is it a new admonition? (To be clear: the recommendation should be heeded even by those using CF versions BEFORE this update and older versions like 11, 10, and so on.)

The TLDR is this: If you create (or are given) a CF "CAR" (ColdFusion ARchive) file, you should treat that as a file that contains passwords, as technically it will, if what was exported into it was in fact any CF Admin setting which holds a password (there are several). No, the passwords are not in plain text within the CAR (which is just a zip). But the info needed to decrypt the passwords is in that file, and the CF Admin INTO WHICH such a CAR is imported will now have those passwords enabled within that CF Admin. Perhaps more dismaying, a savvy coder could easily use that info to convert the "encrypted" passwords into plain text in a single line of code. So one SHOULD indeed take care to secure such CAR files (if not delete them after use).

Do I have your attention now? Just a bit more tldr to preface the post...

Is the concern really unique to CAR files alone? And is deleting the CAR files the only way to "secure" them? No, but a difference is that CAR files may be passed around in a way that other "sensitive" CF files would not be. Indeed, what about the process of simply transporting them from one server to another? Should you be as concerned about that? And what if you don't WANT to delete them because they hold the CF Admin settings of record for an old CF instance you are removing? Should you even be concerned that a colleague also accessing your CF Admin might now use the info identified here to try to obtain a CAR file and use it in ways they should not? And what can you do to limit that? Finally, what about other tools that can save/transfer admin settings, like CFConfig in commandbox?

If you're interested in what's up (and if you or anyone on your server uses the CF Archive mechanism at all, you should be), then do read on. Same if you are not aware of what CAR files are used for, as I will explain.

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

How and why your sites may break, and what to do, after applying March 2020 update to CF2018 or 2016

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....]

Did you know that CF2018 imports environment vars into the Server scope?

This is a hidden gem that I never saw documented anywhere: CF2018 now imports environment variables into the CF "server" scope, specifically:

server.system.environment

and java system properties into:

server.system.properties

(Thanks to Sean C for catching a mistake in the initial post.)

I learned of it last year when Pete F tweeted about it, and I assumed someone else would do a post about it, but the topic came up in a discussion today and I was surprised to not be able to find any mention of it, other than that and his mention of it in his cfdocs.org site.

And yes, Lucee had it first (as proposed initially in 2015). :-)

The feature can be useful, whether you're setting such vars when running a (Docker) container, or via JVM args, etc., and you want to be able to access them within CFML.

More Entries

Copyright ©2021 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting