Skip to main content
D
Daniel232329128pmi
Participant
February 18, 2022
Answered

Can't upgrade jdk past 11.0.10 (CF2021)

  • February 18, 2022
  • 1 reply
  • 1767 views

We got a request in today to update java to 11.0.14 (latest). This is our only 2021 server, but it's been up for a bit and unfortunately was installed prior to the version that defaulted to java 11.0.11. We have no issue moving to any version from 11.0.2 up through 11.0.10. Any version after that won't start the service. The only output for an error is:

Element JDKPATH is undefined in FORM. The specific sequence of files included or processed is: E:\ColdFusion2021\cfusion\wwwroot\CFIDE\administrator\settings\jvm.cfm, line: 227 "
    This topic has been closed for replies.
    Correct answer Daniel232329128pmi

    Hi all,

    I got a chance to dig into this more. I did a fresh install of coldfusion 2021 on a new server and had no issues. So I took its JVM config and copied over the java args. At that point, my current server could get past 11.0.10 with no issue. The removed lines ended up being 

    -Djava.security.manager

    -Djava.security.policy={application.home}\\lib\\coldfusion.policy

    -Djava.security.auth.policy={application.home}\\lib\\neo_jaas.policy

    -Dlog4j2.formatMsgNoLookups=true

    We haven't done too much with this server overall. However, we did follow a few guides during the log4j mishaps. I'm guessing these came from this.

    Again though, thank you so much for the help and tips. It was a great learning experience.


    I had spoken slightly too soon. I reached back out to the client and they said they did need the sandbox security set (the clients local IT added it when putting in content). Ultimately, this issue turned out to be: https://community.adobe.com/t5/coldfusion-discussions/coldfusion-2021-conflict-between-sandbox-security-and-java-11-0-11/m-p/12207456

     

    I applied the workaround provided by Charlie into the jvm.config args -Djdk.lang.Process.allowAmbiguousCommands=true

    1 reply

    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    February 19, 2022

    The error "Element JDKPATH is undefined in FORM" is usually caused by a bitness mismatch. That is, a 32Bit <> 64Bit mismatch, where you install a 32Bit JDK for 64Bit ColdFusion or a 64Bit JDK for 32Bit ColdFusion.

     

    See, for example, https://community.adobe.com/t5/coldfusion-discussions/element-jdkpath-is-undefined-in-form-after-java-upgrade/td-p/3451613 

     

    If that is so in your case, the solution will be obvious:

    • Install a 32Bit JDK for 32Bit ColdFusion or a 64Bit JDK for 64Bit ColdFusion
    D
    Daniel232329128pmiAuthor
    Participant
    February 21, 2022

    The error message is misleading. JDK 11.0.11 (or newer) shows and OS architecture of x86_x64, despite being pulled explicitly from the x64 version of the java page, implying it's agnostic to either. We checked 11.0.10 which showed it running x64 on ColdFusion (versions all pulled from the same pages).

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    February 25, 2022

    Thanks for sharing your jvm.config. The file could indeed do with some corrections:

    1.  Change the value of java.home to point to a recent JDK, For example, JDK 11.0.14.
    2.  Increase the heap sizes from -Xms256m -Xmx1024m to, for example, -Xms1024m -Xmx2048m
           In any case, use a minimum xmx of -Xmx2048m. Use preferably -Xmx4096m (assming the Operating System has sufficient RAM).
           That recommendation can be deduced from the ColdFusion 2021 System Requirements. CF2021's memory requirements are: "2 GB of available RAM for ColdFusion runtime and ColdFusion-related services. (Recommended: 4 GB)."
    3.  Delete the following 3 settings, as they seem experimental (the hard-coded paths are a no-no):
          -Djava.security.manager
          "-Djava.security.policy=E:\\ColdFusion2021\\cfusion\\lib\\coldfusion.policy"
          "-Djava.security.auth.policy=E:\\ColdFusion2021\\cfusion\\lib\\neo_jaas.policy"
    4.  The java.args setting should then be something like
      java.args=-server
-Xms1024m
-Xmx2048m
-XX:+UseParallelGC
-Xdebug
-Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005
--add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
--add-opens=java.base/java.nio=ALL-UNNAMED
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/sun.util.cldr=ALL-UNNAMED
--add-opens=java.base/sun.util.locale.provider=ALL-UNNAMED
--add-opens=java.base/java.net=ALL-UNNAMED
--add-opens=java.base/java.io=ALL-UNNAMED
-Djdk.attach.allowAttachSelf=true
-Dcoldfusion.home={application.home}
-Duser.language=en
-Dcoldfusion.rootDir={application.home}
-Dcoldfusion.libPath={application.home}/lib
-Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER=true
-Dcoldfusion.jsafe.defaultalgo=FIPS186Random
-Dorg.eclipse.jetty.util.log.class=org.eclipse.jetty.util.log.JavaUtilLog
-Djava.util.logging.config.file={application.home}/lib/logging.properties
-Dtika.config=tika-config.xml
-Djava.locale.providers=COMPAT,SPI
-Dsun.font.layoutengine=icu
-Dcom.sun.media.jai.disableMediaLib=true
-Dlog4j2.formatMsgNoLookups=true
-Dcoldfusion.classPath={application.home}/lib/updates,{application.home}/lib/,{application.home}/gateway/lib/,{application.home}/wwwroot/WEB-INF/cfform/jars,{application.home}/bin/cf-osgicli.jar​

    Well, I see a couple of things differently. First, the 4g in the sys req is for the presumed default 1g heap in CF. It's not proposing that everyone should necesarily RAISE that to 4g. Indeed, then you could need MORE than the 4g of system ram. As you note, folks can only raise the heap if they DO have available ram.

     

    Does someone running at 1g NEED to raise it? That's a totally different question. Many run just fine at 1g (or even less) of heap in CF, yes even with CF2021. There are SO many variables that control the need of heap. Anyway, that setting would NOT influence whether CF can start with JAva 11.0.11 or above, which is Daniel's issue here.

     

    Now let's talk about the security manager args. Those are not "experimental" (there are indeed many jvm args--including ones that some use all the time, which are considered experimental).  Someone may want to point out that the security manager is marked for deprecation as of the current Java 17 LTS version, but even there it IS still supported, so is also in Java 11. Here even are docs for it, for Java 11.

     

    Now, by default CF does NOT enable those security manager args (java.security.policy), unless you enable the CF "sandbox security" feature. So Daniel, are you guys using the CF Sandbox Security feature in this CF instance? If you go to the CF Admin Security page, and its Sandbox Security tab, is the option indicated as enabled/checked? If not, then you don't need these args. If you are, then you do.

     

    So back to BKBK's noticing them: again I am not aware of anything about Java 11.0.11 or above that changes anything about the security manager, so the args SHOULD work. But if you eitehr are NOT using the Sandbox feature, or if you are tempted to see if removing that arg will help, do let us know how it goes.

     

    We could dig in more, based on your throughts in reply, or perhaps BKBK or others will have more to say. Hope that's helpful. As I've said from the beginning, it sure feels like you have something environmentally different from a normal installation ("amiss on your end", as I said). This is one example of a difference from the norm. There may still be others to explain things.

    /Charlie (troubleshooter, carehart. org)
      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices