I am porting a legacy application with about 500.000 lines of code (with horrible architecture, as usual 😉) from ACF to Lucee. Most of the stuff requires just minor adjustments, but I have one case where an app specific mapping is not available inside a CFC and and therefore instantiation of another CFC instantiation fails. It's a case of

include cfm

->

include cfm

->

include cfm

->

include cfm

->

call CFC method

->

new mapped.path.OtherCFC()

. In the last cfm I can dump

this.mappings

and everything is there, but in the CFC method none of those are available. I tried

GetPageContext().getConfig().getApplicationMappings()

to see which mappings are available, but apparently that does not list app specific mappings. Does anybody have an idea how I could go about finding out why the mappings are "missing" or how to fix that?

are you using Application.cfc level mappings ? I understand these are only available within the same Application, global mappings are created in the Lucee admin ?

Application.cfc level... and it is within the same application

If you add the mapping to the Lucee Admin (server) - does it then work? If so - you, too, are a victim of LDEV-694 Please vote for it!

I think this is the case of application defined mappings being available at runtime but not compile time im guessing it works for cfincludes but not e.g in an extends statement

The ticket I linked shows how ACF adds the context of the servlet container to the path - which Lucee does not yet do.

From memory I think this will work with lucee admin defined mappings and also the environment variable defined ones

Here is a Lucee forums thread, where @bdw429s steers me through it all (well for my use-case)

If you’re problem is runtime vs compile time and you are using CommandBox, you can use cfconfig to create the server level mappings automatically using a .cfconfig.json file. I believe cfconfig can be used outside of CommandBox too but I've never used it that way (not sure why anyone would really).

@gavinbaumanis this has nothing to do with webserver virtual mappings, as a matter of fact there is no webserver mapping for that specific directory.

@chris-schmitz either I'm misunderstanding what you are doing in the code, or I cannot replicate it so there might be some other idiosyncrasy in play. Here's my attempt based on what you said: https://github.com/adamcameron/cfml/tree/lucee_mapping_issue/community/chrisSchmitz/luceeMappingsIssue This works A-OK on both CF2021 and Lucee

Yes @chris-schmitz I'm saying that both the extends and new calls will not work with mapping defined in Application.cfc

I can reproduce a similar-seeming problem in ColdFusion where it does not respect

import

statements when using the unqualified class reference in an

extends

. But Lucee handles this fine. I cannot reproduce any issue with extends / new / import / fully-qualified / un-qualified names and runtime Application.cfc-defined mappings on Lucee. Which, to be honest, rather surprises me.

@Adam Cameron I tried to create a test case for the better part of this afternoon, too, and in that test case the mappings work, like you said. I tried to mimic the original application's structure and file names as much as possible, but still: test case works, actual application fails. But things got even more confusing... in the actual application the mapping is named

modul

(without an 'e', they use the German name here). If I do

fileExists( expandPath( 'modul/path/to/any.cfc'  ) )

in a CFC method, the file is found, so the mapping is working. If I do

new <http://modul.path.to|modul.path.to>.any()

right in the next line, it says the component can't be found. And the result is the same if I use the old fashioned

createObject()

instead. I then tried the appoach @cfsimplicity mentioned in https://blog.simplicityweb.co.uk/123/forcing-lucee-to-re-check-the-physical-paths-of-application-defined-mappings-without-a-restart ... and did a loop over

GetPageContext().getConfig().getApplicationMappings()

and displayed

getPhysical()

for every mapping ... and I found mappings of a different application (different application name). 😞

and I found mappings of a different application

That sounds like a smoking gun.

it's in a docker dev environment. I did that. several times... no change

Ok so where are these other mappings coming from then?

@chris-schmitz Do you see the same incorrect mappings when you output

getApplicationMetadata().mappings

. That is the documented way to get that data

Sorry, I was not clear... after the restart the other mappings were gone until that other application was hit. With "no change" I meant that I still cannot instantiate a CFC with a mapping path from within another CFC.

Using an app-specific mapping does work in my experience for creating and extending CFC. ColdBox does this all the time since we auto-create a mapping that points to every module so you can do

new myModule.models.foo()

and I've never had an issue with it.

@bdw429s in

getApplicationMetadata()

couple of values seem right, but some seem wrong, e.g. the mapping struct is empty

My recommendation here is what I usually recommend-- simplify the problem domain, keeping the errant behavior but eliminating as much stuff as possible until you can get it worked down to the simplest reproducible form. So basically, create a copy of this and start ripping out pieces until it's as simple as possible, but still breaks. Sometimes in doing so, you find a bug on your end, and if not, you finally have a nice stand-alone repro case you can use for the ticket 🙂

This isn't this stupid thing you and I have encountered before @bdw429s where like as well as the

/modul

mapping, there's also a dir at

/modul

in the file system, or in the web root (or application root? Can't remember) and Lucee is deciding that's what you mean instead of your same-named mapping?

That's a great question/point. A good test would be to change it to

/foo

and see if it changes the behavior

I was also about to suggest start deleting stuff between where the code is going wrong and the initial file being hit. Keep removing code until the problem stops.

great points Adam and Brad, I got to go now, but, tomorrow I'll check this out!

Keep us posted mate.

Sorry for the hiatus in updating you, as I said in the Adobe channel, my time and energy were occupied by other events. iSorry for the hiatus, as I said in

I'm actually surprised that mappings set in

onRequest

even works. I dunno why, but I would kinda expect all that sorta stuff to need to be set before the CFML engine starts to service the request. I have no basis for this thinking, but the practice seems... odd to me. Still: if it works at all, it should work uniformly, and should not be able to be thwarted by other CFML code. I note that neither CF nor Lucee actually document where in Application.cfc

this.mappings

ought to be set, both just say "in Application.cfc"

yeah, I use to set mappings in the pseudo constructor as well and was quite surprised that it was done differently here. I, too, could not find a hint where in Application.cfc you need to set the mappings.

Try this https://docs.lucee.org/guides/Various/system-properties.html

@zackster this does not have any impact on the behaviour, at least in my demo case

Can confirm, @chris-schmitz, I see the same thing you do

I have created an issue here: https://luceeserver.atlassian.net/browse/LDEV-4031