Hi Charlie Arehart , I’m migrating from CF11 to cf18 and I have got a back up of all neo*.xml files of cf11 project. I was referring to docs ( https://forums.adobe.com/message/10661306#10661306 ) and I have done all the required settings in both IIS server and CFAdmin but still getting java.null.pointer exception.
In the java and jvm setting of cfadmin the jvm args are
( -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 -server –add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED –add-opens=java.base/java.nio=ALL-UNNAMED –add-modules=java.xml.ws –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 -XX:MaxMetaspaceSize=192m -XX:+UseParallelGC -Xbatch -Djdk.attach.allowAttachSelf=true -Dcoldfusion.home={application.home} -Duser.language=en -Dcoldfusion.rootDir={application.home} -Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true -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 -Djava.locale.providers=COMPAT,SPI -Dsun.font.layoutengine=icu ).
There is some UNNAMED args in that is this causing the null pointer exception?
Please help me I’m new to this.

No, there’s nothing wrong about those args referring to “unnamed”. That’s as it should be. (Those args with two dashes are new for Java 9, and thus for CF2018, which runs for now on Java 10.)

And while the display here makes it look like yours (like add-opens) have only one dash in front of them, I suspect that what’s happened is simply that the portal editor or display mechanism has rendered those two dashes as a single long dash (and “em dash”).

Bottom line: your jvm args here look fine. (I did a compare of yours to mine, and they were identical.)

One gotcha that just got me is with cflogin when moving from CF10 to 2018.

In CF 8, 9, and 10 this worked great:

Main (root) Application.cfc just used to authenticate via cflogin and set an ApplicationToken e.g. RootToken.

Different applications in sub-folders that required a login had their own Application.cfc with different application names but with <cflogin applicationtoken=”RootToken” >. This gave my server a single sign on (SSO) without any extra application overhead between sub-applications within my site.

Once I upgraded to 2018, none of these sub-applications worked because the user was not logged in. I tried “extending” the Application.cfc files and using an ApplicationProxy file, but that didn’t work. Eventually, I just renamed all my sub-applications to the same name, which made the whole site one big application and that worked. I liked the old way better though. I also don’t understand what the point of the ApplicationToken attribute for cflogin is now.

Hopefully this will keep someone else from beating their head against a wall for too long…

(I see that two people asked about 8, and Anit a has answered them each individually with the same answer. As I wanted to offer a counterpoint (to both), I’m posting this as a new comment rather than duplicating a reply to each.)