During a recent server migration I found that some per-application mappings pointing to locations outside the webroot were being wrongly resolved because the directories hadn’t yet been created.
Ben has described the situation in more detail and as he says at the end, it seems that failed mapping resolutions are cached somewhere, meaning that creating the directories post-hoc has no effect.
Restarting the engine will force re-resolution, but does anyone know of a way of clearing cached mapping resolutions short of that?
Don’t forget to tell us about your stack!
Lucee Version: 22.214.171.124
you could try refreshing them by updating them?
actually, the recommend way is with Administrator.cfc (cfadmin is considered a bit internal and subject to change)
Thanks Zac, but
getMappings() only seems to return those defined in the administrator, not per-application mappings. If I try to use
updateMapping() I get an error (for the same reason).
try this then
Defines scoping for an application, enables or disables storing client variables, and specifies a client variable storage mechanism. By default, client variables are disabled. Also, enables session variables and sets timeouts for session and...
No effect I’m afraid Zac.
getApplicationSettings().mappings returns the correct path resolution, but then it’s only telling you what your code has specified, not what Lucee has actually resolved and cached.
application action="update" is presumably equivalent to reloading the application, but I’d already tried that and it doesn’t cause the mappings to be resolved anew.
application action="update" mappings="#getApplicationSettings().mappings#";
No difference I’m afraid, Zac.
do you have the stack trace for when the broken mapping problem occurs?
time to file a bug, for the initial bug and that the update doesn’t work.
ideally lucee should retry to recover the mapping on each request till it’s ok, that’s less overhead than throwing an exception and muchnice
There’s no stack trace because there’s no error.
ExpandPath( "/mymapping" ) simply returns the wrong path, ie. a directory below the webroot, when it should be a location outside the webroot.
I’m not sure it’s a bug as such, more of a needed feature: the ability to re-resolve application.cfc defined mappings that have initially failed because the directory didn’t exist when the app was first called.
Will create a ticket when I get a chance. Cheers for your input Zac.
so in that case, the mapping should take precedence regardless of the filesystem?
No, but if the missing directory is subsequently created, there needs to be a way of telling Lucee to try again instead of continuing to use the (apparently) cached below-the-webroot value until the next engine restart.
…And I seem to have just found it!
lucee.runtime.MappingImpl has a method
check() which does exactly that.
I feel a blog post coming on…
Request for an official solution
for( mapping in GetPageContext().getConfig().getApplicationMapping() ) mapping.check();