Cfclass folders are populating with unknown code

Stack:
Windows server. We have a Main application with a bunch of shared code in a central shared area. Then each subfolder contains extended versions of the core application with some customizations in the local subfolder. The Main Application has a WEB-INF folder with Lucee’s default(?) cfclasses in that.
Each subfolder also has its own WEB-INF folder with cfclasses in it. Each subfolder and the main folder are all mapped to different websites in IIS.

Our issue is that when we push the servers live we are seeing “missing class” errors where it’s looking into the Root WEB-INF and not finding specific folders and subfolders. The only way we can force the page to load is to delete the contents \SharedMainCodeBase\WEB-INF\lucee\cfclasses and to rerun the page. Then it starts populating that \SharedMainCodeBase\WEB-INF\lucee\cfclasses folder again.

The issue is that each time we start a new service or server, we have to keep deleting out the folders from that central location. Which we can’t keep doing long term. We keep getting an error that \SharedMainCodeBase\inetpub\company\htdocs\WEB-INF\lucee\cfclasses\CF__servenameb_fc01_inetpub_OurCompany_htdocs__ourtemplates14325\lucee\runtime\PagePlus.class where the path lucee\runtime\PagePlus.class doesn’t exist.

OS: Windows Server 2012R
Java Version: 11.0.7 (AdobeOpenJDK) 64 bit
Tomcat Version: 9.0.35
Lucee Version: 5.3.7.47

Any help would be very appreciated.

you’re nesting contexts?

/main/WEB-INF
/main/sub1/WEB-INF
/main/sub2/WEB-INF

Yes.
www.ourmaindomain.com maps in IIS to \sharedfileserver\ourmaindomain\WEB-INF

Then www.someotherdomain.com maps in IIS to \sharedfileserver\outmaindomain\someotherdomainfolder\WEB-INF

Is that the right approach or is that why the web inf folders are messing up? We could just use the top level web inf I guess. If we can somehow turn off the sub directories and have all the sites use a single web inf. Is that what is recommended?

try this

We just upgraded Lucee from 4.5 or so, and we’ve just updated to 5.3. We have used the same mapped dives and directories on the web server. (IIS)
We know the main “site” has a WEB-INF directory that seems to be a parent LUCEE STUFF (classes and logs) of the sub folders. Each subdomain is a unique web application that shares some of the same code as the parent application.
When we upgrade Lucee on each server we are seeing errors that indicate a missing class (ie, /PagePlus). Or It cannot find a path to a
\fileserver-fc01\inetpub\MainCompanySite\htdocs\WEB-INF\lucee\cfclasses\CF__fileserver_fc01_inetpub_MainCompanySite_htdocs6937\lucee\runtime\PagePlus.class

\\fileserver-fc01\validfolder\WEB-INF\lucee\cfclasses\companyname_htdocs6937\lucee\runtime\PagePlus.classCaused by java.io.filenotfound exception.
Why is it looking for a not found runtime directory within the cached filestructure under WEB-INF? And why did the sub mappings work and not error in the old version? We didn’t change any file/server mappings. With the upgrade this happens intermittently for various pages on sites and other various pages on other subdomain websites at (seemingly) random times?

The directory exists all the way to the \companyname_htdocs6937\ subfolder and doesn’t contain the following folders: \lucee\runtime****.class

Are there default settings in the Lucee5 installer that may have overwritten older settings in the Administrator that could possibly cause this issue?

In your reply, are you suggesting to us to consolidate all of the “main” application and all of the “sub” applications/domains to share one single WEB-INF folder [on a drive other than the default drive] so that we can make sure all of the sites and sub sites share only one web context?

I think you might get into trouble when nesting contexts at some point. This might go well in some situations, but you will probably run into conflicts because each domain; because Tomcat creates the WEB-INF folder for each web context by default in its own webroot.

Because Tomcat is creating WEB-INF for each subfolders, Tomcat might/will identify these as new added physical folders of the parent application. It might scan those and try to add them to the web context of the main parent applications web context. I imagine that is why @Zac_Spitzer recommended to try moving the WEB-INF folders outside of these webroots with the link he has provided. By doing this you’ll avoid any creation of WEB-INF direcories in the subfolders and thus it will be “hidden” from Tomcats scanning process of the parent main application.