This.mappings not picking up new settings

dev support
1

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?

2

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:

3

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.

4

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
5

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
6

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

7

@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.

8

@ImShogun Hello my friend :smiley:

9

Hey there, sorry to revive this topic but I’m having an issue that I think is related to this one:

I am using the ortussolutions/commandbox:lucee5 docker image.

component {
this.webrootDir = "/app/myapp";
this.mappings["/api"]="#this.webrootDir#/server/api";
this.mappings["/myapp"]="#this.webrootDir#";
}

Now the interesting part:

  • Calling localhost:8080/myapp/index.cfm serves me the page I expect it to.

  • Callng localhost:8080/api greets me with an error

Page /api/index.cfm [/app/api/index.cfm] not found

Furthermore, calling localhost:8080/myapp/server/api/index.cfm is greeting me with the expected page.

I know that the directory exists and Lucee does so too, it seems, when asking for the exact path. However, it won’t apply the mapping for /api.

Am I missing something here?

EDIT: added information about using the docker image

10

I could be wrong here, but I don’t think this type of “mappings” affects incoming URLs. I have only ever used mappings inside of the runtime to create CFCs or references files via expandPath() and cfinclude , for example.

To have an incoming request mapped to a location, I think you would need to do that at the web-server level (like in nginx or apache maybe) … but, to be honest, I’m not really a server person.

1 Like
11

@bennadel Thank you! Your input was the last piece to the puzzle.

Realizing that my server should handle url rewriting, I wrote a rule for commandbox [1] and it is working as expected.

[1]: CommandBox and URL rewrites made easy

1 Like
12

Nice!! Glad to be able to help, if only indirectly :smiley: