https://bz.apache.org/bugzilla/show_bug.cgi?id=61877
--- Comment #6 from Mark Thomas <ma...@apache.org> --- (In reply to Christopher Schultz from comment #4) <snip/> > (In reply to Mark Thomas from comment #1) > > As far as I recall, no configuration files are read from CATALINA_HOME. They > > are always read, and only read, from CATALINA_BASE. I don't think making the > > default web.xml an exception is a good idea. > > Counterexamples: if CATALINA_BASE/conf/context.xml is not present, > CATALINA_HOME/conf/context.xml will be read instead. Code reference please. The only code I can find always reads from CATALINA_BASE. > Also, > CATALINA_HOME/bin/setenv.sh is executed if CATALINA_BASE/bin/setenv.sh does > not exist (this may be considered something other than a "configuration > file", but I think it helps illustrate the point). That is historical. Originally, it was read only from CATALINA_HOME. The point was made (bug 43594) that it made more sense to be read from CATALINA_BASE. The fall-back to CATALINA_HOME is there for backwards compatibility. > There are at least *some* files that Tomcat will fall-back to in > CATALINA_HOME if they are not present in CATALINA_BASE. It's "surprising"[1] > to find out that a "stock" configuration file -- one users are actively > discouraged from editing -- does not enjoy this kind of fall-back semantics. > > [1] https://en.wikipedia.org/wiki/Principle_of_least_astonishment As far as I can tell there is a single file and it behaves this way for backwards compatibility reasons. In all other cases configuration is read only from CATALINA_BASE. I would argue that it is more surprising to change that. Additionally, web.xml has merging rules applied to it. Is the proposal that CATALINA_BASE/conf/web.xml is merged on top of CATALINA_HOME/conf/web.xml or only CATALINA_BASE/conf/web.xml is used? With the former option, a complex process will get more complex and user applications might break - in theory a security issue be introduced. That means the behaviour needs to be made optional which creates more complexity. With the latter option, the same issues exists except the merging complexity. Overall, this seems like an awful lot of effort to address a documentation issue that looks like it could be fixed with a couple of sentences. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
