My pleasure, @BILL314613570ssy . Thanks to you too for sharing your solution! ... View more

Perhaps it was marked for installation, but something went wrong during installation.  Try the following steps, which helped to solve a similar package-installation issue in ColdFusion 2023:   Stop ColdFusion 2023; Open the Command Prompt (cmd) as Administrator; Use the DOS cd command to navigate to  {CF2023_HOME_DIR}/cfusion/bin;  Type cfpm and press ENTER. You should get ColdFusion's package manager prompt cfpm;  Run the command uninstall all Wait for the CFPM tool to finish uninstalling all the packages. Then, leaving the Command Prompt window open, restart the ColdFusion service;  Run the CFPM command install all 8.  Note down the name of any package that the CFPM tool says has not been installed or could not be installed. Keep running the command install all till the result is either an irreversible error or ColdFusion tells you that "All the packages are already installed". 9. If any packages were not installed or if there were errors, then share that with the forum. Otherwise, restart the ColdFusion 2023 service. 10. Test by running the code  - or by doing whatever it is that you did - that caused the error. ... View more

I have filed a bug ticket: https://tracker.adobe.com/#/view/CF-4229152 <cfscript> testStruct = {"key1" = 1, }; testArray = ["item1", ]; writeDump(var=testStruct, label="Test Struct"); writeDump(var=testArray, label="Test Array"); </cfscript>   The code runs successfully on ColdFusion 2025 and on every version of Lucee since 4.5. On every previous ColdFusion version, the code results in an error, thereby breaking backward compatibility. ... View more

Charlie, I have been experimenting a lot with the generation of Java bytecode in ColdFusion - to *.class files as well as to *cfm and *.cfc files. I have also been engaged in a study investigating the ways in which malicious attackers could use them to undermine a server. However, thanks for the reference. I will check it out. There are always things to learn from others.   To respond to your remark, I did not say that such *.class files are the concern of the change preventing the execution of cfml pages comprising Java  bytecode. This point is crucial. So I shall clarify once again. ColdFusion has the very unsafe tradition of being able to directly run Java bytecode (essentially class files) that are stored with *cfm, .*.cfc or *.cfr extension. Such files result from applying cfcompile without the -deploy flag. The new change prevents ColdFusion from running such files directly. You have comprehensively discussed that point, as I acknowledged.   That was the first case. There is a second case: the Java bytecode that results from applying cfcompile with the -deploy flag. The result is the same Java bytecode as before, but now stored as *.class files. Provided these were on the classpath, ColdFusion would gladly execute them. The new JVM flag would not prevent that.   To repeat, I had assumed that @Dordrecht asked for a way to distinguish between any such previously precompiled class files and the classes that ColdFusion currently generates as a result of the setting "Save class files". ... View more

The situation is: You have one instance of ColdFusion 2023, installed on Windows. You wish to install the latest ColdFusion 2023 update, and prefer to do so by means of the Graphical User Interface in the ColdFusion Administrator.    Yes, I would recommend that you back up the entire ColdFusion 2023 directory before applying the latest update. Proceed as follows: - Stop ColdFusion 2023. -  Copy the entire ColdFusion2023 directory -> ColdFusion2023_backup_before_Update17. -  Apply the update (currently Update 17). -  If, for any reason, ColdFusion 2023 fails to start or if there is a significant error you can't solve, restore the backup directory as "ColdFusion2023" and start ColdFusion.   Yes, it is recommended to restart ColdFusion just before applying an update. From my experience with applying updates through the Administrator, it has never been necessary to also restart any of the other services (ODBC Agent, ODBC Server, .NET Service, Add-On Services). It has always been sufficient to restart just the ColdFusion Application Server. However, you should expect to restart any of the related services, should an issue occur in its communication with the Application server.     As your installation is currently Update 16, when you apply Update 17 connector recreation is not required. But there is one caveat. Let us suppose the unlikely scenario that the update breaks the server, and you have to restore the ColdFusion2023 directory. Then. on rare occasions, web server connector binaries may need re-running. I think the "8122" mentioned in the documentation is a typographical error. The port in the connector example is clearly 8022. ... View more

2) But finally (and I think more important), I do have to counter the rest of what you offered to dordrecht, in your final section on "determining whether there is any Java bytecode representing CFML files located anywhere in a legacy application".  Your whole premise there is on finding .jar or .class files (other than in cfclasses) that hold the compilation of cfml code.  Well, no. There's no need for that effort.   Such .class files are NOT what this change is about. To be clear, it's about cfm or cfc files...which may hold WITHIN them bytecode....which is done traditionally by the cfcompile script in cfusion's bin. But as Brian's post (which I pointed to) made clear and actually demostrates, the problem is that someone could also just copy such bytecode (of their own creation) into such a .cfm or .cfc file. (And even then, the main concern he was raising was that then such code might be able to do things that the CF Sandbox feature would have otherwise prevented executing at runtime. His observation was that such compiled bytecode in a cfc or cfm file circumvents that sandbox protection, if enabled.)   Anyway, the main point of contention I'm making here (regarding your suggesiton that he search for and start decompiling .class files) is that it's just not necessary: there's no way that CF will execute a .class file. That's not a feature of CF. Again the protection of this recent change is merely to prevent running of cfm or cfc files which CONTAIN such bytecode.   And so yes, the challenge some might have is finding any such .cfc, .cfm, .cfml files (but NOT .class files) holding such bytecode, if they wonder whether the new default blocking of that would affect those.  And that is indeed why I proposed searching for *.cf* files.     By @Charlie Arehart I can now see a point you're making, @Charlie Arehart . But it's not the whole story. A clarification is in order. The Java bytecode that this thread is about represents a *.class file - even when the bytecode is stored as a *.cfm or *.cfc file. For example, if you use cfcompile without the -deploy flag, you will get a *.cfm or *.cfc file (the ones you're referring to). However, with the -deploy flag, the bytecode is stored as a *.class file.   I had assumed that @Dordrecht asked for a way to differentiate any such previously precompiled class files from the classes that ColdFusion currently generates as a result of the setting "Save class files". ... View more

I agree with you. Like you, I think it's a bug in ColkdFusion 2025. You should report it. ... View more

Thanks for the update, @moalspvic . Fingers crossed - good luck! ... View more

BKBK, thanks for reaching out. The PROD machine in question has all packages installed already.  By @moalspvic I think you misunderstand. What I propose is that you re-install all the packages using the CFPM tool. The hope is that the process will download and install any missing packages. ... View more

I'd like to add a few thoughts in reply to bkbk's counterpoint.   1) First, thanks for your acknowledgment in the first sentence. As for your then saying to dordrecht that " your question is certainly not ridiculous", I just want to make clear that I didn't say it was nor did my reply convey that. I get that you maybe did  not mean to imply that, ... etc. etc.    By @Charlie Arehart @Charlie Arehart , my post was not intended as a counterpoint to yours. As I said, it represents my own perspective. ... View more

My pleasure, @Dordrecht . Glad to have helped. ... View more

Hi @Dordrecht ,  @Charlie Arehart's response is comprehensive and touches on the main points of your question. I have a different perspective.  First of all, your question is certainly not ridiculous. It is in fact important. After all, the JVM flag concerns the security of your server. Yes, the flag  -Dcoldfusion.compiler.block.bytecode=true prevents ColdFusion from executing pre-compiled CFML code (Java bytecode) at runtime. Yes, ColdFusion works by executing precompiled Java bytecode at runtime. Yes, with "Save class files" turned on in the Administrator, ColdFusion will be able to run the precompiled class files that it caches (normally in \WEB-INF\cfclasses). In other words, ColdFusion is able to run its own precompiled Java bytecode in spite of the JVM flag being switched on. So, what's up? There is no contradiction. The first statement should actually have read, "Yes, the flag -Dcoldfusion.compiler.block.bytecode=true prevents ColdFusion from executing any pre-compiled CFML code (Java bytecode) at runtime from an untrusted or unauthorized path". The new security measure to enforce the path authorization is the setting "bytecodeexecutionpaths". It specifies a whitelist of directory paths from which the server is permitted to execute precompiled Java bytecode. The setting is in the configuration file pathfilter.json discussed by Charlie. Its default location is /lib/pathfilter.json. Check it out. The default setting is: "bytecodeexecutionpaths": "" As C:\\ColdFusion\\cfusion\\wwwroot\\WEB-INF\\cfclasses\\* is not on this list, why then is ColdFusion able to run the class files? Answer: because this particular directory is authorirized by default and trusted by ColdFusion. With  -Dcoldfusion.compiler.block.bytecode=true enabled, if ColdFusion attempts to run Java bytecode that is on some other path that is not listed in "bytecodeexecutionpaths", an exception will occur.   Now, on to the question of determining whether there is any Java bytecode representing CFML files located anywhere in a legacy application. I would do it manually, as a separate project, away from the application, as follows: Create a directory called MyAppJavaBytecode. Create within it 2 subdirectories, classes and jars. Search the application for *.class files and *.jar files. (From the foregoing, the search excludes the \WEB-INF\cfclasses\ directory and directories such as \cfusion\lib\ which are authorized to be in the classpath.)  Also remember: the search is for *.class files and *.jar files that represent CFM pages or CFCs. So, there is no need to include CurrentCustomerYearAccounts2025.class if it's known for sure that it represents the class for CurrentCustomerYearAccounts2025.java. For the same reason, there is no need to include CurrentCustomerYearAccounts.jar or ColdFusion's Jar files. If the search locates a *.class file, and the file is suspected to represent a CFM or CFC file, then the file is copied to MyAppJavaBytecode/classes. If the search locates a *.jar file, and the file is suspected to represent CFM or CFC files, then the file is copied to MyAppJavaBytecode/jars. Assuming some *.class files have been found, create a ZIP of the folder MyAppJavaBytecode/classes.  Use a Java Decompiler to decompile the ZIP as one batch, and any suspect Jar files found. . Such decompilers usually have a search function. Use it to search for the strings "import coldfusion.runtime.CFPage", "import coldfusion.runtime.CfJspPage" and "import coldfusion.runtime.CFComponent". The first two suggest the bytecode of a CFM page; the last two suggest that of a CFC. ... View more

My pleasure, @Dynamic_critic9200 . I'm glad to have helped. ... View more

Sorry for the oversight. On my installation it's the same port. To confirm the correct Solr port, go to the ColdFusion Administrator page Data & Services > Solr Server.    For good measure, verify that http://localhost:8997/solr/#/ (or the equivalent in your system) shows the Solr dashboard ... View more

Yes, @Dynamic_critic9200 . Remember to:  Verify that 8993 is the correct port. You can do so in the ColdFusion Administrator, on the page Data & Services > PDF Service.  Comment out the existing host and port lines in jetty-http.xml: <!--<Set name="host"><Property name="jetty.http.host" deprecated="jetty.host" /></Set>--> <!--<Set name="port"><Property name="jetty.http.port" deprecated="jetty.port" default="8080" /></Set>--> Restart ColdFusion.         ... View more

This subject was discussed extensively in a thread posted last September. See https://community.adobe.com/t5/coldfusion-discussions/cold-fusion-2023-restrict-access-to-solr-web-app-to-localhost-on-server-with-ipv6/m-p/15489261 . You will find many ideas and suggestions there. ... View more

Wow, @Junaid32092262a1i8 , what an interesting find! The flag -Dcoldfusion.literal.preservetype is indeed relevant.  Thanks for sharing it. Are you sure about the flag -Dcoldfusion.lang.mfunctions.enabled? What does it do? Is there any reference to it?  I have searched but cannot find anything on it. ... View more

@Junaid32092262a1i8 , following up on your last observation, I made a discovery. In ColdFusion 2021 as well as in ColdFusion 2023 (on Trycf.com), the code <cfset mongoQuery1 = {"active": true, "$exists": {"field": true}} /> <cfoutput> <p> #mongoQuery1.active.getClass()#<br> #mongoQuery1.$exists.field.getClass()#<br> <p> </cfoutput> <cfset mongoQuery2 = {"active": javacast("boolean",true), "$exists": {"field": javacast("boolean",true)}} /> <cfoutput> <p> #mongoQuery2.active.getClass()#<br> #mongoQuery2.$exists.field.getClass()#<br> <p> </cfoutput> results in: class coldfusion.runtime.CFBoolean class coldfusion.runtime.CFBoolean class java.lang.Boolean class java.lang.Boolean   This tells us that:  Inside the Java Virtual Machine, ColdFusion's True is represented by the "wrapper" type coldfusion.runtime.CFBoolean. This is conceptually similar to Java's wrapper, java.lang.Boolean, but it is Adobe ColdFusion’s own internal Boolean wrapper used by the CFML runtime. So, even though it wraps a boolean value, it is not the same type as java.lang.Boolean. This confirms my earlier statement: "A ColdFusion true is not necessarily the same as a Java true".  ColdFusion 2021 and ColdFusion 2023 produce the same result. Therefore the root cause of the issue is unlikely to be the move from ColdFusion 2021 to ColdFusion 2023. In other words, a change in the underlying Java version from 8 or 11 to 17 is unlikely to be the root cause of the issue.  The root cause is likely to be a change in the behaviour of the Java/MongoDB APIs that ColdFusion is interacting with, or a change in the way ColdFusion interacts with them.     ... View more

Hi Both, ... Could it be that coldfusion 2023 supports Java 17 and in moving from coldfusion 2021 to 2023, Java 17 is causing the issue? By @Junaid32092262a1i8 Good observation, @Junaid32092262a1i8 ! That might be the root cause. ... View more

Thanks for clarifying, @Charlie Arehart . I didn't misunderstand. But I can see why you think I did. I should perhaps have explained more.   @Junaid32092262a1i8 , The situation, as described, is not fair to ColdFusion. The code mentioned does not work in ColdFusion 2021 and then fail in ColdFusion 2023. So there is actually no breaking change. That a ColdFusion true is rejected by Java is not ColdFusion's responsibility. A ColdFusion true is not necessarily the same as a Java true (as you have found out). ColdFusion is weakly-typed, Java strongly-typed. You should therefore convert the type of ColdFusion's variables into a type that is acceptable to whatever interface ColdFusion is communicating with. In this case, Java. Which is why ColdFusion has Javacast.  As the documentation says, Javacast "converts the data type of a ColdFusion variable to a specified Java type to pass as an argument to Java or .NET object. " ... View more

Hi @Junaid32092262a1i8 , As far as I know, there was no change in the handling of boolean type between ColdFusion 2021 and ColdFusion 2023. You can confirm this yourself.   Do the following test, independently of your application, to help you isolate the root cause of your error:  Go to https://trycf.com ;   Select ColdFusion 2023 as engine and run the code <cfset mongoQuery = {"active": true, "$exists": {"field": true}} /> <cfdump var="#mongoQuery#">​  You will see that the code runs as expected. That is, without any errors.   ... View more

No worries, @shashank_4461 . ... View more

Hi @jbird4k2 , Nil desperandum! The Community version of MySQL is free for personal use.  An alternative MySQL database server that is open-source and free for use is MariaDB.   Check out the ColdFusion 2018 Support Matrix. It tells you that the MySQL version you need is 5.7. That corresponds to MariaDB version 10.2. You can download the latest builds of these versions from the archives of the respective sites: MySQL 5.7.44 ( https://downloads.mysql.com/archives/community/ )  MariaDB 10.2.44 ( https://mariadb.org/download/?t=mariadb&o=true&p=mariadb&r=10.2.44&os=windows&cpu=x86_64&pkg=msi&mirror=archive )        ... View more

It definitely is odd - the problem was still happening only on shutdown of the server if we didn't stop CF services first.  We'll bring this finding back to Adobe as well in our ticket and see if this helps. By @matthewr4300865 A ColdFusion restart involves ColdFusion shutdown. Since the issue occurs either during restart or shutdown, it means that it does not involve normal runtime. So I don't see anything odd in that.   Runtime not being involved means that the cause of the issue is unlikely to be your application or ColdFusion (itself a Java application).  As I explained earlier, the error message points to an issue in Java.   The cause likely involves the tearing down or reinitialization of network resources (sockets, threads or bindings). During this tearing down or reinitialization, a race condition, resource-allocation issue, resource-cleanup issue or bug occurs in the native networking stack. In short, the JVM - not your application or ColdFusion - is crashing at a low level (native code), inside the Windows network subsystem used by the JDK.   Talking of resources, what are the values of Xmx and Xms for the affected ColdFusion instance? Values that are too low or too high may contribute to the cause. ... View more

Thanks for the update, I am glad to hear that the JVM flag has stopped the files from being generated.   Yes, this suggests a bug. Not in ColdFusion, but in Java. It's not a coincidence that a JVM flag has an effect on the issue.   That is in fact how I got the idea of testing with -Djava.net.preferIPv4Stack=true (keyword: net). The error message tells us the "problematic frame" is net.dll. This means that: The JVM crashed in the native Windows networking code used by Java’s java.net layer. This is likely unrelated to ColdFusion. This is likely unrelated to your application code. This is most likely a native crash in the JDK, most likely a bug or edge-case in Java’s handling of IPv6.   I would suggest that you (or the Adobe ColdFusion Team) file a Java bug. In the bug report, you might want to include, at least: ColdFusion 2023 application server Running on JDK version (17.0.16 Oracle) OS version (Windows Server 2022) The full hs_err_pidXXXX.log Stacktrace: # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff9ab9557e0, pid=4428, tid=11096 # # JRE version: Java(TM) SE Runtime Environment (17.0.16+12) (build 17.0.16+12-LTS-247) # Java VM: Java HotSpot(TM) 64-Bit Server VM (17.0.16+12-LTS-247, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, parallel gc, windows-amd64) # Problematic frame: # C [net.dll+0x57e0] The JVM flags, showing the difference with and without: Crashes: (with no IPv4 flag); Works (that is, does not crash, when the following flag is applied): -Djava.net.preferIPv4Stack=true Steps to reproduce: Occurs when ColdFusion is restarted. Not reproducible manually after startup unless rebooted. ... View more

Charlie, my answer, though you lament that it is "merely said in a few words", does respond to both questions asked in the original post, namely:  why the Null error occurs.  whether what is observed is the intended behaviour, hence whether or not it is a bug.   Your "elaborated explanation of things" is certainly helpful. However, it contains mistakes.   Paolo has pointed out one of the mistakes. That is, your params?.field2?:true (incorrect) in place of the correct params?.field2?:false. In coding, the standard default boolean for a non-existent variable is false.    There is a second mistake. You suggest arguments.args?.field2?:true, which evaluates to true when the key field2 does not exist in the structure arguments.args. That is incorrect for the reason I've already given.   Finally, I not only agree with Paolo, I think his opinion is profound. His concerns that using safe-navigation together with the elvis operator can affect the reading and understanding of code are real and well-founded. There are occasions, such as in Paolo's function when, for example,  if ( isNull(arguments.args.field2) or !arguments.args.field2 ) { // false } or if ( !structKeyExists(arguments.args, "field2") or !arguments.args.field2 ) { // false } would be more readable and easier to understand than if ( arguments.args ?. field2 ?: false ) { }   This does not mean the combination safe-navigation+elvis is bad. It is elegant when used where optionality is intentional. However, it increases the semantic density, hence the entropy, of the code. As such, it can be less readable and more difficult to understand. ... View more

I'm a bit concerned about using safe-navigation together with the ternary/elvis operator as it affects the reading/understanding of the code in my opinion. What do you think? By @Paolo Olocco I agree with you, @Paolo Olocco .   The safe-navigation and elvis operators each condenses multiple functionalities together, including the underlying assumptions. That is, they increase the code's complexity. In so doing, they make the code more difficult to debug and to maintain than if you had used the operator-less version of the code. ... View more