Recordings and links for my presentations in Jan 2024, Dec 2023
But some people seem to notice when news is shared of a recording being made available, so here you go.:-) These are 4 sessions I've done in Jan 2024 and Dec 2023.
But some people seem to notice when news is shared of a recording being made available, so here you go.:-) These are 4 sessions I've done in Jan 2024 and Dec 2023.
So I'll be presenting a talk on this topic, online this Thursday, at noon US Eastern, on the CFMeetup youtube livestream (which will be recorded). Folks who are members of the Online ColdFusion Meetup will have already gotten email notification about this, including the meeting URL, but for those who are not members here are the details:
So I will be presenting presented a talk on this topic, online this Thursday, at noon US Eastern, on the CFMeetup youtube livestream (which will be was recorded). Folks who are members of the Online ColdFusion Meetup will already have gotten notification about this, but for those who are not, here are the details:
If you run server software that runs atop Java and you learn there's a new Java update available, it may well be relatively simple for you to apply that update if you do it often. If you don't, and you are running important server applications which rely upon Java, then it's in your interest to give some consideration to various matters related to doing such an update. That's the primary focus of this post.
And as important, if you may have skipped some Java updates before this one, there are some additional points to consider regarding some potentially important changes in those updates that you may be skipping.
For more on the above, read on.
TLDR: The new updates are 1.8.0_401 (aka 8u401), 11.0.22, 17.0.10, and 21.0.2 respectively). For more on each of them, including what changed and the security fixes they each contain (including their CVE scores regarding urgency of concerns), see the Oracle resources I list below. Oracle calls them "critical patch updates" (yep, CPU), but they are in fact scheduled quarterly updates, so that "critical" nomenclature may sometimes be a bit overstated. Again, more details below. And as is generally the case with these Java updates, most of them have the same changes and fixes across the four JVM versions, though not always.
For some folks, that's all they need to hear. For others, read on.
So I will be presenting presented this talk online this Thursday, at noon US Eastern, on the CFMeetup youtube livestream (which will be was recorded). Folks who are members of the Online ColdFusion Meetup will already have gotten notification about this, but for those who are not, here are the details:
I will be presenting presented the talk online this Thursday, at noon US Eastern, on the CFMeetup youtube livestream (which will be was recorded). Folks who are members of the Online ColdFusion Meetup will already have gotten notification about this, but for those who are not, here are the details:
If you apply the update using the CF Admin and then find that CF starts but the Admin and your code fail, I cover that also, in the second section below.
For more, read on.
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.If you try to apply ColdFusion updates (including the latest released Oct 6) via the CF admin or command line and find that the update fails, the problem may be due to the JVM you're using (within CF or at the command line). There's a simple solution, which I discuss in this post.
TLDR; If you've configured either CF2021's java home to use Java 11.0.20 or later, or CF2023's java home to use 17.0.8 or later, you may find that applying CF updates ia the Admin will fail. You can apply the update via the command line, adding a needed new jvm arg:
-Djdk.util.zip.disableZip64ExtraFieldValidation=true
(to be placed BEFORE the -jar arg) in the java -jar ... command, as I discuss more in the 5th bullet point below. (If I've lost you with that simple suggestion, read the rest here. And all may benefit reading what precedes that suggestion, for context. I also offer other suggestions and info.)
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.Have you ever wanted to test (from the command line) whether a port on another machine can be reached from yours? When some app of your can't seem to connect to a given port, you may want to test things from the command line. (The problem may be that the service using that port has stopped or is blocked by a firewall--it may be that you're mistaken in the port you are trying to use, or perhaps even the ip address, domain name, or machine name.)
There are in fact many tools which can help with this task, some of which will be familiar to those on *nix systems, but Windows users who've been around a while (or who learned from such folks) may try to rely on the good ol' telnet command (as in telnet [machine] [port]). Unfortunately, they often find out how Microsoft has disabled that tool by default for over a decade (since Windows Vista), and while it can be easily enabled, they may be prevented or understandably reluctant to do that.
In this post, I want to show a couple of command-line alternatives which can do the job easily, one best suited for powershell users (Test-NetConnection), and and two of which would suit those who prefer the command line (cmd) and which are now built-into Windows (the past few years): ssh and curl. No, this is not their primary job but they will suit for this task and it may surprise some to learn they're even built-in options. I'll conclude with still other options available to those on *nix environments (who of course can also use ssh and curl), especially nc (netcat).