There seem to be a problem when interpreting docBase in context definitions, if it contains the string "webapps". For testing, I moved tomcat-docs to a separate directory outside of webapps, then defined a file tomcat-docs.xml in CATALINA_HOME/conf/Catalina/localhost : <Context docBase="${catalina.home}/../something/tomcat-docs"> </Context> When I name that directory "something" as above, everything works ok, http://localhost:12345/tomcat-docs displays the documentation (my tomcat runs on port 12345). When I name that directory "webappsSomething", it is interpreted as "webapps/Something" and loading the application (tomcat docu) fails on start of Tomcat: <Context docBase="${catalina.home}/../webappsSomething/tomcat-docs"> </Context> 08.02.2006 15:25:30 org.apache.catalina.core.StandardContext resourcesStart SCHWERWIEGEND: Error starting static Resources java.lang.IllegalArgumentException: Document base D:\be\JAVA_IDE\jakarta-tomcat-5.5.9\..\webapps\Something\tomcat-docs does not exist or is not a readable directory at org.apache.naming.resources.FileDirContext.setDocBase(FileDirContext.java:140) at org.apache.catalina.core.StandardContext.resourcesStart(StandardContext.java:3754) at org.apache.catalina.core.StandardContext.start(StandardContext.java:3925) Apparently Tomcat is fiddling around with the docBase path as soon as it contains the string webapps - why?
looks like fixed in 5.5.15
Found in 5.5.9, seemed to be fixed in 5.5.15, now in 5.5.17 beta the error is here again.
webapps is the default appBase for the Host, and there's some special processing that occurs when the docBase includes webapps, if Automatic Application Deployment is enabled. Does this still happen to you in 5.5.23?
Hmmm... I tried against the trunk, 5.5.27 (current 5.5.x), and 5.5.9 (original reported version) on Linux (Fedora 8) and 5.5.9 on Windows XP (SP3). I can't reproduce the issue using the tomcat-docs.xml provided, the "D:\be\JAVA_IDE\jakarta-tomcat-5.5.9" path, etc. What am I missing? Thanks.
I can recreate this with the latest 5.5.x and the issue appears to be present in trunk and 6.0.x as well. I have applied the necessary fix to trunk and proposed it for 6.0.x and 5.5.x
This has been fixed in 6.0.x and will be included in 6.0.19 onwards.
This has been fixed in 5.5.x and will be included in 5.5.28 onwards.