Confusion Over this.mappings And expandPath() Not Working In Lucee CFML 5.3.3.62
So, I've spent the last 3-hours this morning trying to understanding why my this.mappings configuration in my Application.cfc ColdFusion component "wasn't working" in Lucee CFML 5.3.3.62. After much trial-and-error and many Google searches, it seems that the evaluation of the this.mappings paths gets "confused" (depending on how you look at it) if you attempt to reference a directory that does not yet exist. To be honest, I had no idea that the physical file-system had any impact whatsoever on the evaluation of CFML mappings; so, it didn't occur to me that a folder had to exist before I tried to reference it in a mapping. That said, I wanted to record my journey here in case anyone else stumbles over the same issue in Lucee CFML 5.3.3.62.
To demonstrate this confusion, let's create an Application.cfc with a single mapping that points to a folder in the file-system that we have not yet created:
component {
this.name = "mappings-demo";
this.webrootDir = getDirectoryFromPath( getCurrentTemplatePath() );
this.mappings = {
"/a": "#this.webrootDir#vendor/lib-a/"
};
}
Notice that we are mapping /a to ./vendor/lib-a. Now, let's create an index file that attempts to consume that mapping:
<cfscript>
dump( expandPath( "/a/config.ini" ) );
</cfscript>
All we're trying to do here is output the evaluation of the mapped path. And, if we run this Lucee CFML code before we create the vendor directory, we get the following page output:
/testing-lucee/a/config.ini
Notice that the reference to /a was not mapped to /vendor/lib-a. Instead, Lucee just used / as a reference to the root of the ColdFusion server.
Ok, now let's try to add another mapping to an existing folder. First, let's update our Application.cfc ColdFusion framework component:
component {
this.name = "mappings-demo";
this.webrootDir = getDirectoryFromPath( getCurrentTemplatePath() );
this.mappings = {
"/a": "#this.webrootDir#vendor/lib-a/",
"/b": "#this.webrootDir#vendor/lib-b/"
};
}
This time, we're mapping /b onto ./vendor/lib-b.
Now, before we attempt to consume this mapping, let's ensure that lib-b actually exists in the physical file-system:
Bens-MBP:testing-lucee bennadel$ pwd
/testing-lucee
Bens-MBP:testing-lucee bennadel$ mkdir -p mappings-demo/vendor/lib-b
And, now that lib-b actually exists, let's update our index.cfm file to try and consume the new /b path mapping:
<cfscript>
dump( expandPath( "/b/config.ini" ) );
</cfscript>
If we run this Lucee CFML code, we get the following output:
/testing-lucee/mappings-demo/vendor/lib-b/config.ini
As you can see, this time, the mapping worked. The prefix /b was successfully mapped to ./vendor/lib-b in the expandPath() evaluation. The only difference in this execution was the fact that the this.mappings folder existed before it was referenced within the Application logic.
It's definitely possible that you will never run into this issue since you are likely to be configuring this.mappings to point to existing folders. However, I was just doing some Research and Development (R&D) and wanted to make sure that my ColdFusion mappings were working before I attempted to consume them. This is when I stumbled upon the fact that the physical folder has to exist first. At least, in Lucee CFML 5.3.3.62.
Epilogue On Cached Paths
If you run into this issue, you may find that a failed this.mappings path evaluation continues to fail even after you create the physical folder. It looks like the path evaluations get cached somewhere in the ColdFusion Application state. At that point, you need to restart the ColdFusion application in order to pickup the correct path evaluation.
Want to use code from this post? Check out the license.
Reader Comments
@All,
Here is a ticket that touches on this topic:
https://luceeserver.atlassian.net/browse/LDEV-1718
And, ironically, I just found a message on this blog from 2013 pointing out
mappingsfail if the folder doesn't exist (from Sumit Verma):Re: www.bennadel.com/blog/2519-expandpath-works-with-coldfusion-s-per-application-mappings.htm#comments_43175
I ran into this recently, Ben, and discovered a workaround to force the mapping physical paths to be re-evaluated without a restart.
https://blog.simplicityweb.co.uk/123/forcing-lucee-to-re-check-the-physical-paths-of-application-defined-mappings-without-a-restart
I've also raised a ticket for an official solution.
This is fixed in 5.3.8
@Julian,
Boo ya!!
@All,
One thing that I just learned is that - in Lucee CFML - relative paths work in application mappings:
www.bennadel.com/blog/4106-using-relative-file-paths-to-configure-application-mappings-in-lucee-cfml-5-3-8-201.htm
All the
getDirectoryFromPath( getCurrentTemplatePath() )hoops that I normally jump through after years of using Adobe ColdFusion are gone. Now, I can simply use../values relative to the location of theApplication.cfcfile. Amazing!