URLs with mapping-tag are throwing 404 error

I am still converting code over from Adobe to Lucee ColdFusion. We have some old templates that are using <cfajaxproxy> and I’m having trouble getting those to work with Lucee. Watching the network traffic shows the page is requesting a URL like /mapping-tag/lucee/core/ajax/JSLoader.cfc?method=get&lib=LuceeAjax. That request is getting a 404 error.

Initially the 404 was due to security lock down steps I had performed on the server. We are using IIS for our web server and I had a request filter blocking URLs for /lucee. When I removed that block it got further but still getting a 404 error.

I notice that the request begins with /mapping-tag/. That folder does not physically exist. I found that it is something baked into Lucee it seems. I think that IIS is still getting tripped up on that folder not existing and blocking it before Lucee can do it’s thing.

Has anyone else run into this issue? How did you resolve it? Do I need a virtual directory defined or something else. Even if you solved it for some other web server or operating system please let me know as I can try to take your solution and make it work with IIS. Thanks for any help or info.

Windows Server 2019
Java 11.0.20 (Eclipse Adoptium)
Apache Tomcat/9.0.78
Lucee stable (Gelert)

I am able to ‘fix’ the 404 error by creating a virtual directory in IIS for mapping-tag and pointing that to the {lucee-server}\context\library\tag folder. Doing this allows the requested .js file to download successfully. But is this the correct thing to do? Does this open up some security hole that I am not aware of?

I think it is similar issue to this one: 404 for /lucee/res IIS BonCode

The problem is that my web server (IIS) is blocking the request to mapping-tag because it does not physically exist on the server. I also got this to work without the virtual directory in IIS by adding a blank file in the request location under the web root. This allows IIS to see the file and think it is there so it goes ahead and passes it through to Lucee.

I like this approach better just because it allows me to be more granular in the security settings that I can use for it. i.e. I can still block /lucee every where else.