What if you want it back? In this post, I explain what changed, why, and how to get the functionality back--albeit at your own risk. For more, read on.
Update: In mid-February 2023, Adobe did re-sign their jars and placed them on the uploads site so that either the CF Admin update download or anyone performing a manual download after that date WOULD get the newly signed jars, and the problem below then no longer happens. (They are now signed as "SHA256withRSA, 4096-bit key".) I leave the rest here still for those who would want to understand what DID happen and why the update jars that were in place then DID change (slightly) for this reason.
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.
For some, that's all they need to hear.
And I could (and probably should) leave it at that. But there are other questions which folks will have, including more on getting those binaries/installers (from Oracle or Adobe), on the difference between those LTS versions and "more recent" Java versions, as well as non-Oracle JVMs, and on licensing matters and more. For those, read on. Perhaps I will split this other stuff out into its own post at some point, so I can just point to it from news of these Java updates.
Migrating or Comparing CF Admin Settings, between instances, versions, and engines
You can learn more (including the description, the online meeting URL, where the recording will be posted, and more) at the meetup event page. FWIW, the session name had to be shortened a bit as presented on the meetup site there and even in the title here. :-)
As a bonus for you, my blog readers, I'll note that I'll be covering the CF migration and CAR features, the Commandbox CFConfig tool (which can be used for more than just "box" instances) and the CF2020 cfsetup tool (which has been shown publicly already), and more.
I'll also have a special surprise for people who "just want to compare the Admin settings of two instances without resorting to command-line tools, or hopping back and forth between browser tabs", using a free cross-platform GUI compare tool (and a simple trick in the CF Admin) which has delighted nearly everyone I've ever shown it to. And the tool can benefit you for far more than this one task. :-)
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.
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:
For more on all this, read on.
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 hidden gem that I never saw documented anywhere: CF2018 now imports environment variables into the CF "server" scope, specifically:
and java system properties into:
(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.
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.I have a really simple solution to offer here, for a problem that has been nagging people running ColdFusion for the past few years. This post may also benefit those NOT running CF, especially if they have found confusing/conflicting information about the Java metaspace error and jvm argument that relates to it.
Perhaps you're getting errors referring to "metaspace" or "OutOfMemoryError: Metaspace", whether in your web sites, error logs, or even the CF Admin, and you wonder "what to do". Or you may be getting odd occurrences of blank pages, and if you look in your coldfusion-error.log you are finding such metaspace errors.
TLDR; In all these cases, the solution is simple (and may seem contrarian to some ears): REMOVE the maxmetaspace element from your JVM arguments. Indeed, I would go so far as to say everyone should simply remove it, even BEFORE you may get errors.
In the post that follows, I will explain how to remove it, including how you need to be VERY careful when doing that. You may also wonder why I recommend removing it, versus raising it. I cover that, as well as a bug report I filed with Adobe related this tis (which was fixed as of CF2021), below.
I also created an abbreviated version of this post, on the Adobe CF portal, if that may interest some readers.
Managed Hosting Services provided by
