The access deniederror seems key. It seems you're running on a MacOS or Linux, right? Did you try running the Java -jar command as root, with sudo or su?  ... View more

OK, this is what I was originally writing before BKBK's last respond and my reply to him.    I have new info report--and I DO believe it will be the solution for anyone (like the OP, Ian) who needs to support calling into the add-on service from some IPV6 address--which the "ipaccess" feature (and that jetty-ipaccess.xml file) does not allow you to whitelist. Apologies that it's a long reply. Lot's to cover/clarify.   TLDR; 1) in the jetty/start.ini file, add to the end a new line (--module=inetaccess, which enables that module) and comment out the existing ipaccess line (#--module=ipaccess, which we will no longer use), and 2) define a jetty-inetaccess.xml (in the \jetty\etc\ folder) with the contents I show below--which WILL allow whitelisting/blacklisting ipv6 or ipv4 addresses (and more). You may find you need to also 3) modify the jetty start.ini to comment out the jetty.http.host line (for reasons I will explain) or use the approach BKBK offered just above to modify the jetty-http.xml). I will explain the relationship of this last point to this whitelist matter, which is not obvious.   1) Indeed, let me point out first that in my initial reply to the OP, Ian, I added as one workaround how an alternative might be to use a hosts file to have the localhost resolve to an ipv4 address. I have since updated that first reply, as there's more to that than meets the eye., and I think it's worth a moment of our time here also.   To be clear, the issue of the jetty whitelist feature we're discussing is NOT about the IP address (or host name) used on a URL to call INTO the add-on service. Instead it's about the IP address FROM WHICH such request is made. That's a key distinction to keep in mind when testing things related to this! 🙂 It's also easy to lose track of even when you're aware of it, as happened to me more than once today.   1b) And as some may need to hear it: let's clarify that all this discussion of whitelisting IPs has NOTHING to do with the ip address of the clients making calls to your CFML code which may then use CF features to call upon the jetty/add-in service, like cfsearch/cfindex/cfcollection for Solr and cfhtmltopdf for pdfG. We're talking about the ip address of the CF server that is connecting to that jetty/add-on service.   That said, as has been shown in previous replies here, you can also DEMONSTRATE calling into the jetty service using a URL that names the server running the jetty service and uses its port. See BKBK's previous replies and screenshots for examples of that.   2) Here's another important point before I discuss the "solution". When it comes to wanting to investigate "what's happening" (when things fail related to this whitelisting), note that there is an available "request log" in the jetty logs folder (formally with the name format of [yyyy_mm_dd]_request.log).. And in that log you can see in its first column the ip address FROM WHICH a request is made. That's key.   And it's when THAT shows an ipv6 address , such as pehaps [0:0:0:0:0:0:0:1], that the default whitelist feature would fail--because that would not match the 127.0.0.1 there by default.  As important, note that this jetty request line will also show the STATUS code returned to this request--which will be a 403 for requests that fail this whitelist check (or due to the blacklist check).   2a) I suspect in Ian's situation (as for many), it's that his machine which is running CF had on the CF Admin "Solr" page its "Solr Server" value set to the default of "localhost"--but his machine resolves that hostname to ::1. Why is that important? As I noted in my revision to the first reply today, I find that when a request is made TO an ipv6 address, the receiving server sees the request as coming FROM an ipv6 address. And so his request would be sent to the add-on service as if it's from his ipv6 address (that 0:0:0:0:0:0:0:1 I mentioned).    And I confirmed this in my own jetty request log--along with it getting a 403, because that "from address" doesn't match the 127.0.0.1 that Adobe puts into that jetty-ipaccess.xml file's whitelist value by default. Yet if one tries to modify that whitelist to add either 0:0:0:0:0:0:0:1 or ::1, the add-on sevice won't start (as discussed earlier today) because this jetty ipaccess module simply does NOT allow ipv6 addresses.    3) And before I offer the new solution, I'll remind readers that I had proposed a couple of alternatives to Ian originally. He's not yet confirmed if he tried them.   One is simply changing the "solr server" value in the CF admin (Solr page) from "localhost" to 127.0.0.1 (when CF and the add-on service are on the same machine). Again I am finding that if you make the call TO an ipv4 address, that causes the recipient to see the request come FROM an ipv4 address, in this case 127.0.0.1--which matches the default whitelist. (Again, you can prove it yourself looking in the jetty request log.   4) But there may well be folks who will be setting up the CF and Solr (add-on) service on different machines, and those may use IPV6, such that they will really PREFER to somehow allow use of ipv6 addresses to be whitelisted. And it seems I have come up with the solution for that. (It was hard-going, as I didn't readily find it discussed ANYWHERE, with regard to Jetty--except in the context of writing java code to cause Jetty to allow it, which most here would NOT want to do. Or now I can add that, like BKBK, I found discussions of XML that looked like what he offered--but it didn't work.)   So what's the solution? Change from using the jetty "ipaccess" module to the jetty "inetaccess" module, which DOES support whitelisting or blacklisting ipv4 and IPV6 files. Then configure the associated xml file for that. How does one do these? Pretty easily, actually. There are just two steps.   5) Step 1: In the jetty/start.ini file, go to the end of the file and add a new line: --module=inetaccess That is key to enables that different module (and it's a step BKBK was missing in his last reply.   I wouild also recommend commenting out the existing ipaccess line, so that all access is controlled by this module. That's easily done. You should find it listed as the current final line in the start.ini file. Just put a hash/pound sign in front of it: #--module=ipaccess While it makes sense to have only one module in control of this access, the only negative to this is that some will read Adobe and other resources that propose changing that jetty-ipaccess.xml file...and such changes will be ignored once this ipaccess module is disabled (just like I reported to BKBK that his proposed new inetaccess xml file was being ignored by Jetty because he'd not yet enabled the module that uses it.)   I think the benfits will outweigh the risk--at least for those who want/need ipv6 control of whitelist/blacklisting. And who knows, perhaps Adobe will see the value in this and switch to using this instead. That could take time to happen, of course.   6) Step 2: Then define a new jetty-inetaccess.xml (in the \jetty\etc\ folder) with contents like I show below--which WILL allow whitelisting/blacklisting ipv6 or ipv4 addresses (and more).  Of course, change it to use the IP addresses you need, for the originating servers that will be calling into your jetty/add-on service (remember to use the jetty request log to confirm what values are coming int and getting 403's). Here is a version of the file that worked for me: <?xml version="1.0"?> <!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "https://jetty.org/configure_10_0.dtd"> <Configure id="Server" class="org.eclipse.jetty.server.Server"> <Call name="insertHandler"> <Arg> <New id="InetAccessHandler" class="org.eclipse.jetty.server.handler.InetAccessHandler"> <Call name="include"> <Arg> <Array type="java.lang.String"> <Item>127.0.0.1</Item> <Item>::1</Item> </Array> </Arg> </Call> <Call name="exclude"> <Arg> <Array type="java.lang.String"> <!--<Item></Item>--> </Array> </Arg> </Call> </New> </Arg> </Call> </Configure> And BKBK, note how different that is from the one you proposed.  I'll repeat: I had found one like you did, but I got the error which I said (in my reply to you) that I got when trying yours. This one does not get errors. More important, if you make any "incorrect" change (like incorrect xml, or changing the name of some element), you would find this one WOULD get errors when the add-on service started.   And of course you do need to restart the add-on service for these changes to take effect.   6a) Before moving on, you'll notice that I have commented out the element for the blacklist (what is referred to in this file and the inetaccess module as an "exclusion" rather than a blacklisting--perhaps a nod to changing norms regarding such terminology). I showed this in case one does not want to blacklist/exclude but only whitelist/include. To be clear, once you list an include, then ONLY requests from the listed ip addresses will be allowed. Others would get that 403 error in the log and on-screen.   6b) Of course, if you wanted to allow calls into jetty from some other IP address, you could add them as another "item" in the first "include" list. For example, I was testing calling into one machine running the add-on service from another, and for that to work I had to add its ip address, in my case: <Item>192.168.68.58</Item> As for how to know the ip address of that other server, course you could just do a command-line ipconfig (or the *nix equivalent, ifconfig) to get that (for whatever network device makes the connection), but I'll remind you again that you can find it just as easily being reported in that first column of that jetty request log, if you make a request to this add-on service from that other server and it's rejected with a 403.   6c) But what if you do NOT see your request (from another server) showing up in the jetty request log--as a 403, or even at all? Well, you may have found that when you ATTEMPTED the request from the other server, you didn't get any 403 error shown but instead the request just hung.   That would be because you probably have to open the firewall on the add-on service to ALLOW such a call in to the add-on service port from another server. That's beyond the scope of this disucssion, but I share it before someone says "I made all these changes and it's still not working for me". Of course, if there's some other problem with anything I reported, I welcome feedback.   6d) But what if it was indeed that the address for that other server was an ipv6 address? Indeed, we would want to add another "item" element...but in terms of what to put in as the value, well, this is where things can get tricky, especially for those not familiar with ipv6 addresses. (Things were easy with the "::1" for a localhost/loopback address.)   Here again, one may be tempted to just go to that other server and do an ipconfig/ifconfig to get the ipv6 address (for whatever network device made the connection). But beware, if you put that into the xml file it may fail to be allowed as you'd expect. Let me share an example.    I went to the other server from which I was making the request (and I had used in the call to the solr server the ipv6 ip address of the CF add-on service server), and I did an ipconfig and found the ip address reported to be:  fe80::4115:17a4:6371:7229%6   And I put that into the xml file as another "item"...but the request still was blocked (with a 403, as tracked in that jetty request log).   So I'll say again: the best thing to do to get the ip address FROM WHICH a request is made is to look in the jetty request log at that first column. When I did that, it showed the ip address instead as: fe80:0:0:0:4115:17a4:6371:7229%27   That's quite different from the one above that I got from the ipconfig. It's similar, butnotice for instance the ":0:0:0:" where before there was just "::". Then of course the closing % values are different. I'll note elaborate on ipv6 details. But I AM saying that until I put the SECOND value into the XML file, it was NOT properly whitelisted: <Item>fe80:0:0:0:4115:17a4:6371:7229%27</Item> Hope that helps folks.   6f) Before wrapping up discussion of the inetaccess module, I will point out that there are indeed other things you can specify in these "item" values, including ip address CIDR values and ranges. I'll leave it with pointing you to the docs for more, as this is already a blog-length reply!   Note that these address values are technically instances of an "InetAddressSet" java class, and the (brief) docs showing examples of other kinds of item values are available here, for the Jetty 9 version that recent CF versions have included.   7) Finally, before wrapping up there's another thing some may readers may find helpful with regard to a DIFFERENT aspect of how the CF Jetty service (or any jetty service) may be configured. (Again, I had already started writing this before BKBK's note, and what I offer will be a bit different than his proposal to tweak the jetty-http.xml file, which is of course a workable option.)   When it comes to calls into the jetty (add-on) service, note that there is YET ANOTHER configuration aspect which relates to what ip address (and port) jetty LISTENS on, meaning what IP addresses you can CALL INTO the service--which is quite different from the whitelist feature, which is instead to control what IP addresses you can CALL FROM.   This is important to understand because sometimes when you may be testing various URLs used to call into the jetty service, the ip addresses or domain names will ultimately reach the server using some ip address (or a hostname that resolves to one), and whether the jetty service is willing to "listen" for requests to that ip address depends on this other configuration. Let me explain with examples.   7a) If you look in that jetty start.ini file (referred to previously in this post and thread), you will find among its values a line called "jetty.http.host", and you may well find it preconfigured to have this value: jetty.http.host=127.0.0.1 That means that jetty has been configured to ONLY listen for requests either TO that IP or for a hostname that RESOLVES to that IP. This is another reason that one may find a failure in calling into jetty. We talked before about how if you're using localhost and your server resolves that to ::1, then that's the request you'll try to reach...and this host value will reject that (differently from the whitelist).    So could you change it to ::1? Well, yes. But then it would ONLY accept requests on that address (calls INTO that address). That could trip up some OTHER request made to jetty.   7c) So what to do if you DO want to let jetty "listen" for calls into more than one ip address (whether ipv4 or ipv6)?   Well, sadly you can't list more than one address on this line...and you can't list two of the lines.    So in fact, in BKBK's previous reply he showed how you one option would to switch gears and use the jetty-http.xml file to name two "connectors" that listen on the different IPs (to which requests could come into this server). That's certainly an option. See his reply for more details.   But I'll share one other option which may suit some folks: if you simply comment out that jetty.http.host line, that will allow jetty to listen to requests on ANY incoming address (again, this is not about the address FROM which a request comes, but the one TO which a request comes). To do that, again just comment it out: #jetty.http.host=127.0.0.1  In doing that, now jetty will listen to requests coming into ANY ip address which the server has, again whether ipv4 or ipv6, so that could include 127.0.0.1, ::1, and indeed others (as you would find from an ipconfig/ifconfig done on the jetty server.)   7c) Now, could someone contend/ask, "well isn't this then the only solution that someone needs" to solve the original problem?   Well, maybe.   First, note that the currently implenented ipaccess module still limits where requests can come FROM. Remember, the original problem Ian presented was wanting to whitelist an ipv6 address--which that module can't do. And I surmised it was because indeed the localhost value on his CF machine resolved to ::1. And the ipaccess whitelist would block that.   So could he instead JUST comment out both this jetty.http.host and the ipaccess module?   Well, yes.   But then you'd be leaving yourself open to relying SOLELY on your firewall to protect you...and you could conceivably have bad-guy calls come into jetty (and solr and pdfg) from somewhere INSIDE your network.   And in fact THAT is why the default value for this jetty.http.host is 127.0.0.1--the presumption is that you ONLY want to allow requests that come INTO that ip address...and generally one can only request that ip address if they are ON the server where jetty is installed.   I realize all this can make your head swim. I hope it makes sense if you read this post carefully, perhaps a couple of times. 🙂   8) Like I said, it's taken me a long time (hours) just to write this up (carefully), not to mention the hours I spent exploring the problem and finding the solution (when it was really hard to find). Of course, now the AI agents will soon find this thread and offer to people THIS XML as the solution to the problem. OK, I'll have done my job.   And you who have read through to this point get to be like explorers of a cavern who get to say you were there when it was discovered. Of course, it's an arduous journey descending into a new cavern. Hope it was worth the trip. Future folks will find the answer presented more succeinctly by the AI agents. And sure, I could have made this far more brief, but as is my wont I wanted to explain things, to try to help others who would take this ball and run with it. I love challenges like this!   And as always, if I have made any mistakes, let me know. Soon I would want to turn this into a blog post--to help those who don't read this forum, and may need the info before the AI bots consume and regurgitate it.   Looking forward to what Ian, BKBK, and anyone else may have to say.  ... View more

Sadly, no. You were on the right track, but I think I will demonstrate to you why this is not doing what you propose.   1) First, yes, you are RIGHT that the solution is to leverage the inetaccess modile. That is indeed what I will be showing. But your file will not work, if you enable that module. The thing is, you have not included the step for enabling that module. (I will.)   2) And if you did enable that module, you would find that your XML would fail, reporting (in the jetty stderr log) that there was a "Config error at <Set name="whiteList">", along with dozens more lines. The thing is, that XML (offered in various places on the web) is simply incorrect. I will offer the correct XML. (And this is what I meant in saying that it was proving difficult to resolve correctly.)   3) But I get it that you may feel I'm wrong in my assertion.  To that I will propose two things.   First, I could propose you change the ip address in your whitelist to something that would never be correct. But second I'd propose you change the xml file to have entirely invalid xml...such as removing half of the file contents. Then save it and restart the add-on service. Does it restart? Are there no errors in the jetty stderr log? If so, that's proving that ketty simply is NOT loading that file (because again, you have not enabled the inetaccess module. And even if you do, your XML will fail as it does for me when I enabled the module. So I will offer the correct xml in my next reply.)   4) So finally, you would reasonably ask "why then am I now able to successfully run the request either way"? I will assert that's because of the OTHER change you made, in the jetty-http.xml. And what you did there is controlling what IP or hostname jetty is willing to LISTEN ON. That's different than this whole whitelist matter, which is instead about what IP address is MAKING THE REQUEST TO JETTY.    So in conclusion, again, all these are things I had planned to address already in my post. And indeed that's why I had not posted it quickly after my previous note. There's a lot to cover, and it is taking care to explain it correctly. I will now get back to doing it.   I hope you'll wait for that before you may reply. I think what I have to say will be beneficial for you about what you offered, in addition to being beneficial to Ian and others who may be following along. We're all in this together, advancing understanding for the CF community. ... View more

Thanks for the update, BKBK. It was an easy mistake to make. Glad I noticed that solr.home value to connect the dots. 🙂   But I have great news (well, some will find it great, I think): I have figured out how to get Solr to let us whitelist an ipv6 address. More in a note I'll be sharing here shortly.  ... View more

BKBK, nope, neither works (not ::1 nor 0:0:0:0:0:0:0:1).   Let's clarify a few things, for everyone's sake. And I think I may see why you are experiencing things differently.   1) First, just to be clear: while he was asking about CF2023, and you are talking about CF2025, the issue is the same for each (at least since the April 2025 CF updates that incorporated the changes in the configuration of the add-on service/jetty/solr/pdfg to rely on this jetty-ipaccess.xml file).   As for why it seems "ok" for you to specify a ipv6 value in that whitelist, I have a couple of thoughts.   2a) First I'd propose a test for you to try: change the value of the whitelist to use ONLY 127.0.0.2 (or any random ip) and restart your add-on service. Then try to visit that localhost:8997 url. (Folks on CF2023 would use 8995, while folks on CF2021 would use 8993.)   The point here is that you SHOULD get an error rejecting that request, if the whitelist is protecting you. If you do not get an error, then your jetty-ipaccess.xml is not doing the protection it should.(And so jetty may not even be loading it let alone verifying it as we're experiencing. And I share below the error we see in the jetty logs.)    And there could be two reasons for that happening for you.    2b) One is that I notice your screenshot of the solr dashboard, it shows one of the values as -Dsolr.solr.home=multicore. From my experience, that's the value one gets if you have implemented the separate add-on installer, in which case of course you need to be editing the jetty-ipaccess.xml within the etc subfolder where THAT was installed. By default, it would be /ColdFusion2025Add-onServices.    Sadly, that solr dashboard does not confirm for us what folder the Solr is running in, beyond that jvm arg. (FWIW, with respect to the Jetty implemented within a CF2025 folder, the value would instead show -Dsolr.solr.home=C:\ColdFusion2025\cfusion\jetty\multicore   2c) Second, along the same lines, in the root of the jetty folder (whereever it's installed) there will be a start.ini. In that file. In that file, do you see a line indicating this: --module=ipaccess You should. In a default CF install of Jetty (at least since those April updates), it's the last line of that file. But of course it doesn't need to be last. It DOES need to not be commented (that start.ini file uses pound signs as comments).   Again, sadly the solr dashboard does not show anywhere a confirmation of this. That's why I started with the test in my point 2a.   3) Finally, just to clarify for Ian and anyone else following along, when things fail as he and I have experienced, not only do we find the add-on service won't start (and that localhost call to the add-on service/jetty/solr/pdfg port will fail), but also in the jetty/logs folder, the one called [yyyy_mm_dd].stderror.log will report the error as "Invalid IP address pattern: ::1" (when attempting what Ian reported originally).   Ian, can you confirm you see that error?   4) If you do see that error, again (as I reported originally), this is not an Adobe problem: it's a jetty problem. And to be clear, Adobe chose (starting with cf9) to bundle the solr feature (technically the add-on service which it's a part of) as an implementation atop Jetty, which is itself another app server implemented within CF. (And in CF11 they also implemented the PDFG feature, for cfhtmltopdf, on the same jetty. Both solr and pdfg are implemented as "web apps" within Jetty. It was never clear why they didn't do it via Tomcat instead.)     It's only when the Jetty project chooses to solve this ipv6 problem in jetty-ipaccess.xml (or there becomes some other way to limit Jetty by ipv6 addresses) that the error will no longer occur.   (As an update since posting this reply, I do think I have found the solution. See my next reply.)   In nay case, BKBK, I will again be very curious to hear what you find when you do the test in my point 2a above, and what you find with respect to points 2b and 2c. Even just as a sanity check for you. 🙂   5) Along those lines (for those following along), when one DOES have this jetty-ipaccess.xml set to whitelist some IP address but your request does NOT come from that (like if it's set to 127.0.0.1 but yuor machine running CF makes that request via IPV6), and you then try to visit the localhost:[jettyport] page (whether you add "/solr" on the URL or not), the error you get for CF2025's add-on service will simply be "HTTP ERROR 403 Forbidden". But the error for CF2023's add-on service will be "HTTP ERROR 500 java.lang.IllegalArgumentException: Invalid IP address: <the ip you tried to use, or the ip the hostname resolved to>".   I suspect that difference has something to do with other aspects of Jetty configuration, like that ipaccess module I referred to in point 2c. Anyway, I offer those also in case others get the error and search for it, so that they may find this discussion.   Hope it proves helpful. ... View more

Good catch on Conner's original 2024 issue. (To be clear to readers, that "settles" only his issue, not the others raised subsequently here.) Would be nice to hear back from him, but it seems reasonable that you've presumed it will be the answer for him.   And thanks also for marking my reply to the more recent (2025) matters here as another "answer".  ... View more

Just to clarify, this is what I was suggesting from the first reply. Glad you feel things are resolved.   For readers who find this thread in the future, the next two posts of mine which follow are actually from earlier in time. The threaded nature of the forum sometimes makes replies like that seem confusing.  ... View more

Yep, I'd experienced the same. And when I looked into it some weeks ago, it seemed this was an unfortunate limitation in Jetty, not something of Adobe's doing. There are a couple of potential workarounds.   First, since you're wanting to define ::1, is it that localhost on the cf machine resolves to that?  If so, had you considered just changing the "Solr Server" page in the cf admin? While the "Solr Host Name" field there does DEFAULT to localhost, note that despite the name of the field you CAN change that "solr host name" specify an ip address instead, such as 127.0.0.1. That would work for some folks.   As for the related "pdf service" page in the CF admin, while it has a pre-defined "localhost" service, note that it's "host name" field is configured by default to a value of 127.0.0.1 (this despite the field's name implying that it might accept only host names). That one works with the default jetty-ipaccess.xml file, since that is the IP address that's whitelisted (and it's ipv4).   Finally, if one somehow needed to, they could use a hosts file on the cf machine to define some hostname that resolved to an ipv4 address. But that should be unnecessary.   Update since posting: I want to refine that last statement. When I wrote it, I was falling into the mistaken presumption (easy to make) that the whitelist and blacklist were about the IP being CALLED, when instead they are about the IP FROM WHICH THE CALL is made.   But it so happens that when you DO make a call TO an IPv6 address (or use a host/domain that resolves to one), the destination IS given the IPv6 address for the machine FROM which the call was made. So technically using a hosts file that defined some host that resolved to 127.0.0.1 WOULD change the request to come from the machine's ipv4 address...which for many would resolve to 127.0.0.1   But the rest of what I said above still applies: the problem is that if in your environment, your CF server might be on some machine that presents to the add-on service an ipv6 address, which would fail to meet the whitelist above--and the challenge is how to allow for that. (Besides the workarounds above, see more I later discovered in subsequent replies below.)   Let us know, Ian, if the suggestion above works for you, or not.  ... View more

Great to hear, @Dynamic_critic9200. Thanks for the shout out.    As for marking it as an answer, well, as bkbk noted in July there's a technicality in that what I offered (then) would not be "the answer" for the ORIGINAL post above (from Apr 2024)--since that was well before the updates and jvm arg I was referring to.    It's too bad, in that people (like you) who somehow find this post would have to read through all those other replies first before getting to mine from July about the jvm arg. FWIW, it's ok for more than one reply to e marked as an answer.   So @BKBK, now that this has come up again, would you object to us (you or me) picking one or more of the original replies from 2024 to be answers, and then also mine from July? (now that it's solved things for two people who've written here, and perhaps others who have not)   As always, just trying to help, not seeking to "earn points".  ... View more

@DNomer,. I did not suggest that you update cf. I suggested that you update the JVM, which Carl in his reply has now confirmed should address issues with sectigo certs.   As for getting that and cf updated correctly (if you want it), again you can work with your folks and engage in back and forth here, but we could have all this solved in as little as 15 minutes, as I've offered a couple of times.   I get it that some feel they "can't hire help", but it's been a couple of days that you've been troubled and it need not be so. I'd think someone would see the economic value in that. But otherwise, hope we've steered you the right direction.  ... View more

That's great to hear your problem is resolved. And in fact getting another serial number from Adobe was the solution the person in the other thread reported 5 months ago. (Sorry, I failed to ink to it in my last reply. I just corrected that.)    But I'll ask you now since this is fresh: did Adobe tell you why a new serial number was needed? More specifically, do you know (or did they tell you) whether the issue was that your cf2023 serial number was for an upgrade license, as I discussed in my last comment?   I'm just trying to help folks who may hit that error in the future.   Finally, for folks still following along, I'll note that I updated that blog post (the one with the code) to address problems raised by folks here and in the other forum thread.  It's rare that I do that to CF Portal posts by others, but it seemed warranted and I hope it avoids some of the confusion people encountered.  ... View more

The error's not actually from the code, but from the underlying code being called via the Admin API.   In fact, someone else reported getting the same error (during their attempt to offline activate CF2023 license 5 months ago). That post is here.    And I just asked them there something I'll now ask d_goldcamp:   Might it be that perhaps you are using (for the currentSN) the serial number of what you (or someone there) had bought as an "upgrade" license? What that means is that you get a 50% discount for upgrading from the immediately preceding CF version--and when you put in a serial number (in both the CF Admin or CF installer) you would be asked to provide BOTH serial numbers.   In the case of the admin API code on that page you linked to, note how it has commented-out a "previousSN" variable (in both the offered templates). I wonder if the code fails with this error if one DOES use an upgrade license for the "currentSN" variable but leaves commented-out this other previousSN var (which should hold the license of the serial number of the immediately precending CF version, so the one for CF2021 in this case).   Sadly, I don't myself have such an "upgrade" license to test this with. ... View more

Glad you got things sorted. That seemed a strange one. So Patty (or Adobe), did anyone determine what was "wrong" with the CF2023 license you were using, to cause this unexpected error?   Might it have been that perhaps you were using what you (or someone there) had bought an "upgrade" license?  What that means is that you get a 50% discount for upgrading from the immediately preceding CF version--and when you put in a serial number (in both the CF Admin or CF installer) you would be asked to provide BOTH serial numbers.   In the case of the admin API code on that page you linked to, note how it has commented-out a "previousSN" variable (in both the offered templates). I wonder if the code fails with this error if one DOES use an upgrade license for the "currentSN" variable but leaves commented-out this other previousSN var (which should hold the license of the serial number of the immediately precending CF version, so the one for CF2021 in this case).   Even if you (and Adobe) don't know/don't recall what the situation was (and they perhaps kindly offered you a new serial number instead of sorting out this error), I leave this idea as something for folks to consider if they find this error when searching for it in the future. In fact, I found this now 5 months on while helping someone else getting that same error. And I'll ask them also, but in case we don't get an answer there I wanted to raise this here.)     Also, sadly, I don't myself have such an "upgrade" license to test this with. ... View more

@DNomer, two things:   1) Have you yet attended to what we spoke of two days ago here, about updating the jvm that CF uses? That may be all that's needed. See also what I'd written that day, appearing somehow BELOW this back-and-forth with Ravi, here.   2) In any case, if you may still want to try the cert import approach (which you say "a experienced tech" tried), a key point is that the cacerts you import into MUST be the one (within the lib/security folder) for the jvm which cf is currently using. Some people (like that tech,. perhaps) follow cookie cutter steps that fail to clarify this.   For instance, if someone HAS changed cf to use a jvm located outside of the cf jre folder, it does no good then to import into the [cf]/jre/lib/security/cacerts; yet some docs (even from Adobe) specifically tell you to do that, without asking that you confirm what jvm cf is using.   You can find that specified in the cf admin, either on the first field of the Java and jvm page, or (as I'd shared originally) on the admin "settings summary" or "system into" pages. When you reported the version info above, you didn't happen to mention WHERE it said the cf jvm was located.   As always, just trying to help. And again you need not slog through back and forth here. We could fix this is as little as 15 mins in a remote screenshare consulting session (see below for more). But I appreciate some want to or have to "go it alone".  ... View more

Well, I'll say again, there may be no "need" (as you put it) to import a cert but rather merely to update the JVM. See more on my first reply above.    BTW, when @DNomer confirmed a couple of days ago that they were indeed on an old jvm version, I'd offered a bit more in reply, though somehow it's appearing BELOW Ravi's response here.   Please do keep us posted on what attempts you made and where things stand. We're all just trying to help.  ... View more

Did you follow the steps outlined in the response marked as the answer here?  See also the few responses that follow, with additional info.   Let us know how that goes.  ... View more

Yep, this stuff is what I work with helping people about daily..   And yep, both those update levels are quite dated, with Cf2023 u5 being from Oct 2023, and jvm 17. 0. 6 being even older from Jan 2023..   As for updating the jvm cf uses, there are cookbooks. Indeed, the last link in my post there points to a resource I created on the key points to beware, which includes both a link to a rather brief post on doing it from Pete Freitag. Then I point to a preso I did (pdf and recording) covering more details, which some will need but many may get by with Pete's post.   As I point out often, the task can be done in minutes for one who knows what they're doing. But for those unfamiliar, any of various mistakes or missteps could leave cf not starting. If this is prod, you'd want to be very careful.   Of course I can help directly, via remote screenshare, getting it done a (nd explaining the key points) in as little as 15 mins, which is also my smallest billable increment. You won't pay for time you don't find to be valuable. More on my rates, approach, satisfaction guarantee, and online calendar at carehart.org/consulting.   Whichever way you go, hope it works out.  ... View more

No need to reinstall cf. Hope I caught you before you did. See my point 2 here for perhaps an easy solution to that problem. I then share some other info that--while you didn't seek it--seems pertinent to raise for someone in your situation.    1) Indeed, let's first make sure others (who may want to offer suggestions) notice that you refer here to cf10. So this is NOT about any sort of problem with CF license activation (with the online Adobe licensing service), as that started only with cf2021.    (And I'll hold off for a moment on why it's dismaying to hear you're on a cf version that's not gotten updates/security fixes in nearly 10 years.)   2) If you have your cf serial number you can just go into the cf admin, click the "i" icon in the top right, and that page has a field for entering the serial number. The license should take effect immediately. (Since cf2021, that serial number is entered instead on the new "licensing and activation" page of the cf admin.)    If somehow you don't know your cf serial number, it was stored in the license.properties in the cfusion/lib for all the years it was running ok. If you take file system backups, you could find it there.   3) Sadly, in all those years there have been some pretty gnarly vulnerabilities discovered in various cf versions. cf2025, 2023, and 2021 are still updated by Adobe with fixes (cf2021 gets its last ones in 2 months, 5 years after it came out.) And since cf10 came out in 2012, it got its last updates in 2017--now nearly 10 years ago.   Indeed, it's entirely possible that this removals of the license key was perpetrated by an outside (or inside) actor, who may have leveraged a vuln that allowed them write access to that file. If you add it back only to find it removed again soon, this seems a likely scenario.   4) And while it's a bit like rearranging deck chairs in the titanic, note that you could at least follow the guidelines for the cf lockdown guide, the version of which is still available online.   Just beware that "closing the castle doors" does not address the bad guys already in the tower, communicating with and perhaps shuttling items with folks across the moat. That also means that if you simply move to a new server (or switch to using Lucee--or even Python or php), you need to address any bad guy files that got in those last (nearly) 10 years that your cf10 was vulnerable.   5) I appreciate such news is daunting, and leads some to freeze with fear. There are folks (myself or other consultants) who can help you rectify things--either as they stand on that server with cf10 (better locking it down, and/or removing bad guys), or in getting you safely to a new server. And of course we can help with the better solution of getting you on a supported Cf version, or to another cfml engine (both of which come with a price of dealing with migration/compatibility).   6) One way to look at things is that (while playing Russian roulette) you've avoided thousands in cf licensing costs: you'd have paid a total of about us$6250 if you'd have updated CF Standard each time to cf11, 2016, 2018, 2021, and 2023, getting a 50% upgrade discount on the approx 2499 cost each time--thus 5*1250 or 6250 ). Or you could have just paid the full price of 2499 for cf2023.   But now that Cf2025 had come out and is subscription only, someone on cf standard pays just a little more per year: us$760, as documented in the Adobe site in various places.  My point is that the cost of paying now for help is just repaying technical debt you've been accruing/avoiding. And this is to help either to stay on a better- (though never fully) secured cf10, and/or move (carefully) to a new server if the current one is comprised, or move to a new Cf version, or move to a different cfml server (Lucee, boxlang).   But again you just want to get cf10 not being the dev edition. I hope my point 2 above does that for you. Please let us know either way.  ... View more

Two points of potentially beneficial clarification:   First, If it was truly a proxy limitation, I'd point out that the "settings" tab on the package manager page offers a means to configure cf to use such a proxy.   But instead, it may be that some a/v (or similar) tool on your machine is limiting what software can call out to the internet, or where it can call. More advanced versions of that are SIEM and EPP tools, especially if your machine is in an IT-controlled network.   Often such tools can be configured to permit access to allow certain urls and/or domain names to be accessible. If you might be able to add that packages url (and what it redirects to), then you could perhaps avoid that manual offline update dance.   Still, as you found in that Adobe blog post (or again in the cf update technotes), that's not too arduous a dance. But one must be careful: it's easy to make a false step or take a shortcut that could make even that manual process fail. We here often help folks deal with that, so the alternatives above are offered as a heads-up for any they may benefit. 🙂    Again, glad you're sorted for now.  ... View more

The gui and the cli both run the same wsconfig.jar ultimately, and thus the same appcmd under the covers (the actual windows cli tool that performs config of iis) .   And yes, you should be able to rerun things if needed.   Hope you'll try my first proposal.  ... View more

Not aware of any "double calls" issue. As for the inability to remove all, try stopping both cf and iis. Does that work?   If not there is a manual approach. Let's see if the simpler approach works.  ... View more

Nope, just the hope of something "maybe" coming. Or maybe someone else will have more to say.  ... View more

Glad you're working again. And I appreciate that you solved that jar problems by copying a file.    But for others who may find this in the future, that should not have been necessary. The fact that it was needed could indicate a problem in the steps you performed for the manual update. (Did you extract the zip to a new folder and point the cf packages url to that? Or did you instead extract the zip into the cf bundles folder? That's a shortcut some take which is not what the technote says to do.)   Or it could indicate a problem in cf's package management mechanism. (And for some people, such jar errors go away if they clear that felix-cache folder--yes, even right after the update.)   But again, you're sorted for now. If problems recur when you move on to the next update that comes out, perhaps this may be helpful for you then--or for others facing such problems.  ... View more

That certainly seem your problem right there. (If you'd have simply tried the package downgrade I proposed earlier today, you may have also gotten that message. I don't see that you responded to or tried that).   So you say you're the one who did the update from 14 to 15. We should have pressed you to ask if there were any fatalerrors reported in the install log for the update (in the cfusion/hf-updates folder for the update 15). Or was there any several lines from the bottom, when the update would have tried to download package updates. I suspect you'd have seen one or the other.   As for the solution, this is what each update technote discusses as the need of a manual offline update. See there for details (downloading a zip, configuring cf to use that).   Better still since this is your own dev workstation, see if you can fix it so that your computer (cf) can access that url, so the automatic package update process can work.   Or seen what bkbk may offer instead. We're probably writing at the same time.  ... View more

Lots to consider, Robin. Here's some "good" news: that's not some strange problem unique to you, though thankfully it's rare. And there WILL be an explanation and solution: you need not merely suffer the problem.   And yes, there may well be a log explaining it, or something you can enable to understand it.   First, let's clarify: you start saying cf "went down", but then you say you "restarted" it. Did you have to START it (because cf was stopped)? Or did you really restart it, meaning only it was somehow hung? And if you did that, did it restart readily?    If cf truly crashes (goes from running to not running), it will usually write an "hserr" (Hotspot jvm crash) log within the cfusion/bin folder--not where most folks ever consider looking. If you have one there (at the time being considered), read the first few lines of it to see where it reports the cause and tell us.    Assuming there's none or that it did hang rather than crashed, sadly you often won't find an explanation for that. That said, one possibility (which you didn't mention) is the coldfusion-error.log. In there, is there any o "utofmemory" error at the time or just prior to the hangup?    Finally, if none of those bear fruit, in my experience (helping folks solve such problems about weekly for nearly 20 years) the next best step is to implement FusionReactor as a monitor. While it's commercial, there's a free 14-day trial. Besides the very helpful metrics it captures, it also creates valuable logs which nearly always help point directly to the problem.    (There's also the free Adobe PMT tool, which some find to be heavy-handed in its resource usage especially if implemented on the same server as cf, or challenging to implement on a separate server.)    As for what may be amiss, there can be many explanations. For example, I've helped people find it was some single request that when executed (perhaps with unusual form selections) overtook available resources.   A more common problem, especially recently, is an unexpected significant increase in traffic (either in volume or nature). Some folks dismiss that as they presume their measures of traffic show no such increase, but they're being misled.   This was found in another thread here just days ago. And as I anticipated, it was ai bots, search engine crawlers, and other automated requests causing the problem. As for how best to solve that, there are many possible solutions, some easier than others, but they all require careful consideration. It all becomes more clear with the right diagnostics and perspective.    And sometimes we may find that there is a need to modify some configuration settings. It's hard to say from the outside what's "right" for everyone. Again a tool like fr can help in coming up with approprate settings.    And to be clear, you don't have to go this alone, or await/wade through back and forth here. I help people assess (and if needed, implement) such diagnostics to find and resolve such problems about daily (and often in less than hour). If interested, you can find more on my rates, approach, satisfaction guarantee, online calendar, and more at carehart.org/consulting.    Otherwise, besides responding to me--and awaiting possible input from others--there are indeed many resources online that elaborate on these things, from blog posts to presos to forum threads like this. Sadly, there's no single resource gathering those all up. (I created one years ago as cf9f11.com, but it was a lot of work and rarely was referenced. When I removed it, no one complained. We live and learn.)    Anyway, we're here for you. Looking forward to your response. Again, you need not suffer this hangup for long. There will be a resolution, hopefully quickly.  ... View more

Next, on that package manager page, under installed packages, find the oracle one. Which version is it now? Then pick the next older one and choose to downgrade to it.    On the prompt which appears, watch for it warning if doing that would also downgrade the "core". If it does not, then let the downgrade of the package proceed, which will NOT restart CF.    Then do your testing. If it works, we can discuss later why this was needed. If it does not, you could upgrade the package to the version you started with.    Finally, bkbk may have different thoughts now that you've answered his question.  ... View more

Thx for the confirmation.  ... View more

Good to point out, though of course this thread is about how the problem in this (July) update which sadly REMOVED any previous pathfilter.json (replacing it with a essentially empty default file). You don't mention experiencing that.   Indeed, you say "I updated the pathfilter.json with my allowed paths, restarted CF and all is well." Perhaps you're saying you were aware of the problem (and were prepared for it), which is indeed good news. 🙂    And then maybe you're just wanting to let folks know how the problem of the PREVIOUS update is fixed (the message you're seeing, and the tasks no longer being deleted during startup).  Indeed it is. 🙂 And it's mentioned in the update technote, under "bugs fixed", but not with the clarity you've offered. That will help others who may find the thread. Thanks.  ... View more