https://bz.apache.org/bugzilla/show_bug.cgi?id=63740
Bug ID: 63740
Summary: Host-specific xml files are not processed when xmlBase
is not null
Product: Tomcat 9
Version: 9.0.24
Hardware: PC
OS: All
Status: NEW
Keywords: PatchAvailable
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: uk...@atlas.cz
Target Milestone: -----
Created attachment 36769
--> https://bz.apache.org/bugzilla/attachment.cgi?id=36769&action=edit
proposed fix
This is a Tomcat 9 - specific bug. Tested with Tomcat 9.0.24. Tomcat 8.5.43
works correctly. Earlier versions not tested.
When using a Host with xmlBase attribute the Host-specific context.xml.default
and web.xml.default files are not processed at all (because they are not
found).
Debugging the problem reveals that Tomcat searches for them in the wrong place:
always in ${catalina.base}/conf/${xmlBase} instead of ${xmlBase} (when xmlBase
is absolute) or ${catalina.base}/${xmlBase} (when xmlBase is relative).
Examples:
for xmlBase="conf/cx" tomcat searches in "${catalina.base}/conf/conf/cx"
but should search in "${catalina.base}/conf/cx"
for xmlBase="H:/myhost" tomcat searches in "${catalina.base}/conf/H:/myhost"
but should search in "H:/myhost"
Workarounds: using symlinks (a nuisance at best) or using Tomcat 8.5.
Analysis: the documentation says that when xmlBase is not specified then
"conf/<engine_name>/<host_name>" will be used as default. However,
Container.getConfigPath() does not prepend "conf/" when xmlBase is null,
and to compensate for this error the (only) 2 callers use
ConfigFileLoader.getSource().getConfResource()
instead of the correct
ConfigFileLoader.getSource().getResource()
This becomes a problem when xmlBase is not null: getConfResouce() prepends
"conf/".
Proposed fix (see attached patch):
- Container.getConfigPath(): prepend "conf/" when xmlBase is null
- ContextConfig.contextConfig() and ContextConfig.getWebXmlSource():
call ConfigFileLoader.getSource().getResource() when working with the result of
Container.getConfigPath()
Proposed fix tested successfully in 3 scenarios:
- no xmlBase: OK
- relative xmlBase: OK
- absolute xmlBase: OK
How to easily test that the fix works:
- for context.xml.default: the log contains (example)
"Successfully processed context [/my-ws] configuration file
[file:/H:/myhost/context.xml.default]"
- for web.xml.default: declare a filter in it with a (unique) nonexistent
className and expect to see a "ClassNotFoundException" with that className
Thanks for fixing this.
--
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
