This is a bizarre issue indeed. What is more surprising is that other web applications (Spring/non-UI) have the similar configuration (i.e. <Context> entry in the server.xml) and they work just fine, in this environment. Always. And this one application, in this environment, fails. Always.
Everything works in all other identical environments. Always. Having limited access isn't helping either. I will try to enable debug logging and see if gives any clues. Thank you for your input. Thanks, Amit ________________________________ From: Mark Thomas <[email protected]> Sent: Wednesday, June 24, 2026 2:37 AM To: [email protected] <[email protected]> Subject: Re: Interesting issue while deploying an angular application (Tomcat 10.1.x) On 23/06/2026 20:48, Amit Pande via users wrote: > > We have an angular based web application with a bunch of static resources. > > The war is present under the "webapps" app base. > > Understandably it is NOT right way (and fixed in later deployments), but the > server.xml has: > > > <Context path="/ui"> ... </Context> > > This caused an issue while deploying and accessing this application on a > Windows 2019 setup. > I don't have full access to this environment and hence could not do more > debugging than necessary. > > Gemini AI gave a below possible explanation to this very rare problem (there > were multiple identical setups and none of them seen any issue). > > > This <Context> tag sits inside a <Host> container where appBase="webapps" and > it causes Tomcat to get into a race condition: > Auto-Deployer: Tomcat scans the webapps folder, sees a folder named ui, and > deploys it automatically as a standard web app. > Explicit Deployer: Tomcat reads server.xml, sees your <Context path="/ui"> > block, and tries to deploy a second application mapped to /ui using an > absolute path reference. > Because of this conflict, Tomcat splits the application in memory. The > initial mapping (which handles the 302 redirect) belongs to one deployment > instance, but when it goes to fetch index.html or test.txt, it looks at the > explicit server.xml context instance. > Potential cause of this: > > Due to differences in disk speed, CPU core scheduling, or security > file-locking delays (like an EDR agent scanning the files on boot), the > server.xml parser registers the context first. This breaks the link to the > physical webapps directory, causing the files to become invisible to the web > server. > > Does this explanation seem reasonable? No. It is complete and utter AI delusional nonsense. If the WAR is called ui.war then Tomcat will deploy the web application based on the server.xml config. If auto-deployment is enabled this runs later and will skip ui.war and the /ui directory as the web application has already been deployed. If the WAR is called other.war then you will end up with two completely independent web applications. One at /ui from server.xml and one at /other from auto-deployment. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
