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
  Target Milestone: -----

Created attachment 36769
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

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).

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
instead of the correct
This becomes a problem when xmlBase is not null: getConfResouce() prepends

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

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
- 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:
For additional commands, e-mail:

Reply via email to