Amit,
On 6/24/26 8:37 AM, Amit Pande via users wrote:
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.
I wonder if it's a letter-case issue between the file names. Can you
confirm that the filename as seen by Java matches *exactly* with the
deployment directory you are trying to use?
If you have a case-insensitive filesystem, it can mask these kinds of
oddities where the Java String-comparison fails, but the filesystem
treats the two string values as the same thing.
-chris
________________________________
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
