This.mappings not picking up new settings

I feel like I am going crazy! I setup an Application.cfc with something super simple like this:

component {
	this.name = "mappings";
	this.applicationTimeout = createTimeSpan( 0, 0, 0, 10 );
	this.sessionManagement = false;

	this.webrootDir = getDirectoryFromPath( getCurrentTemplatePath() );
	this.mappings = {
		"/": this.webrootDir,
		"/here": "#this.webrootDir#some/thing/over/here/"
	};
}

Then, in my index.cfm file, I am just trying to see if the mappings are working:

<cfscript>
	dump( expandPath( "/here/data.json" ) );
</cfscript>

If this is the first time I run the application, this will work and expandPath() will return the right path. However, if I then go back into my Application.cfc and add a new mapping:

	this.mappings = {
		"/": this.webrootDir,
		"/here": "#this.webrootDir#some/thing/over/here/",
		"/there": "#this.webrootDir#some/thing/over/there/"
	};

… and update the index.cfm file to use /there:

<cfscript>
	dump( expandPath( "/there/data.json" ) );
</cfscript>

… It sees the file in the root of the Application. To be clear, I have the Server and Web contexts setup to always look for changes. Literally nothing I do will add the path. Not even restarting the Lucee (CommandBox) server. The only thing that works is renaming the directory that my code is in. At that point, the new path mapping seems to be picked up.

I’ve been trying different things for the last 2-hours and I cannot for the life of me figure out what is going on. I even tried the “update application settings” technique using getApplicationSettings() and could not get that to work either.

I’m on Lucee 5.3.3.62 using CommandBox on my Mac OS. Is there something about application settings caching that I am not finding in the docs?

Small update. It looks like if the very first use of the mapping is expandPath(), the mapping seems to broken for the rest of the application. However, if the very first use is the creation of a new component, then the mapping seems to work for the rest of the application.

For example, if I go into the Application.cfc and add:

this.mappings[ "/test2" ] = "....some-path..../test2";

And then, do this in my index.cfm:

<cfscript>
    dump( expandPath( "/test2/data.json ) );
</cfscript>

… the path will be wrong and the mapping never works. However, if I try to repeat the same thing with another mapping:

this.mappings[ "/test3" ] = "....some-path..../test3";

… and then do this in the index.cfm:

<cfscript>
    dump( new test3.Thing() );
    dump( expandPath( "/test3/data.json ) );
</cfscript>

… then both the CFC and the expandPath() call seem to work properly. This is very confusing :smiley:

Ok, another update. It looks like the new path.to.Thing() seems to work because the directory exists. If I go back, and add another mapping:

this.mappings[ "/test4" ] = "....some-path..../test4";

And then go and create that folder test4, then the first call to the expandPath("/test4") works. So, it seems that the folder has to physically exist in order for the expandPath() to work. I didn’t realize this. Some more googling seems to indicate that this may be related to this ticket:

https://luceeserver.atlassian.net/browse/LDEV-1718

… where some sort of “physical path” is preferred? I didn’t really understand the ticket.

Anyway, I tried to document this for better “Google Search” results next time I run into it:

And, ironically, I just found a message from Sumit Verma in 2013 saying exactly this:

One thing to be careful about expand path is, it doesn’t work if the file or directory doesn’t exist. It doesn’t throw error, but it returns wrong path.

Oh well, there goes 3-hours I’ll never get back :rofl:

1 Like

I Ben,

I’ve no way to give you your 3 hours back although I was hoping so (I’ve been leeching your articles for more than a decade :-)).

I just wanted to add that to me there should be either an explicit error about the requirement, or no requirement.

That previous paragraph is stating the obvious, but is also just an excuse to say hi :wink:

1 Like

FWIW, I would recommend staying away from / mappings as they’ve cause me nothing but issues. I tried and tried to use a / mapping when switching to Lucee 5 in the CommandBox CLI to work around changes in the 'web root" as the CLI saw it and just ran into issue after issue. Here’s a highlight of the issues related to / mappings. most of these have been fixed, but I’m still leery of it.

https://luceeserver.atlassian.net/browse/LDEV-1728
https://luceeserver.atlassian.net/browse/LDEV-1718
https://luceeserver.atlassian.net/browse/LDEV-775
https://luceeserver.atlassian.net/browse/LDEV-666

@bdw429s I thought that the / mapping was the root issue. But, when I wrote-up my blog-post, I did so without the / and the same issue occurs. I assume this is because / is just using the root of the Lucee app. But, I agree with you, I include / out of habit; not because I actually need it in most cases.

@ImShogun Hello my friend :smiley: