Bug 57892 - Log once a warning if a symbolic link is ignored (e.g. to web.xml )
Summary: Log once a warning if a symbolic link is ignored (e.g. to web.xml )
Status: RESOLVED DUPLICATE of bug 64871
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 7.0.56
Hardware: PC Linux
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2015-05-05 13:53 UTC by Ralf Hauser
Modified: 2020-11-06 14:18 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Hauser 2015-05-05 13:53:15 UTC
In private WebXml ContextConfig.getDefaultWebXmlFragment() or also getWebXmlSource() nothing is found if the web.xml is a symlink.

Please add a message to stderr/catalina.out if the system ignores an existing web.xml


In an eclipse installation, I use several configurations in server.xml like

<Context path=""
docBase="/home/me/workspace/project1/" reloadable="true"
workDir="/home/me/workspace/project1/work" ...

If the web.xml is symlink it fails.

Such an error message would have saved me quite some time.
Comment 1 Mark Thomas 2015-05-05 14:01:21 UTC
The behaviour w.r.t. symlinks is documented under the allowLinking attribute of the context (note it moves to Resources in 8.0.x). Any linked resource is ignored by default.

I'm not convinced that only web.xml deserves special treatment.

We probably don't want a message on every attempted access. One message per application the first time any symlink is skipped is probably sufficient.

In terms of log level, WARN seems most appropriate.
Comment 2 Ralf Hauser 2015-05-05 23:00:00 UTC
Agreed such warnings need not be restricted to web.xml

Also agreed that not every attempted access needs to be warned.
But I would warn once per attempted distinct path as there is sometimes quite some log output and users who grep for their filename wouldn't necessarily find it if it wasn't the first one.
Comment 3 Mark Thomas 2020-11-06 14:18:46 UTC

*** This bug has been marked as a duplicate of bug 64871 ***