we have created a virtual directory on \\10.10.10.81\Recordings and have placed an xml file (recordings.xml) in $APACHEDIR\conf\catalina\localhost on our web server (10.10.10.80). When 10.10.10.81 is rebooted, or goes off-network, the webserver reports the directory as unreadable (error message below) AND THEN DELETES RECORDINGS.XML. Needless to say, this isn't desired behavior. java.lang.IllegalArgumentException: Document base \\10.10.10.81\Recordings does not exist or is not a readable directory SEVERE: Context [/Recordings] startup failed due to previous errors INFO: Container org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/Recordings] has not been started
the contents of recordings.xml: <Context path="/Recordings" docBase="//10.10.10.81/Recordings" debug="0" reloadable="true" />
Agreed this is bad behavior. Oddly enough, I can't seem to find that error message in the current code. So the code must have changed.
Do you have the anti(Resource|JAR)Locking flag enabled? I see a place in org.apache.catalina.startup.ContextConfig#antiLocking (line 964 in current SVN version of code) that deletes the docBase file. These two flags are false by default, so you probably don't have them enabled, but I still wanted to ask. (See http://tomcat.apache.org/tomcat-5.5-doc/config/context.html for the configuration explanation of these two flags). Also, if you wouldn't mind testing on v5.5.20, the latest stable release, that'd be awesome.
I tried to repro this on 5.5.20 with no success. I created a standalone webapp directory (in ${CATALINA_BASE}/test) and a context file (under ${CATALINA_BASE}/conf/Catalina/localhost) that referenced it. I included 'path' and 'reloadable' attributes as in the OP's post. I then tested initial deployment and redeployment of the webapp with the webapp directory both readable and unreadable by the tomcat process user. In all circumstances when the webapp was unreadable the webapp failed to deploy (or redeploy) with an IllegalArgumentException, but the context file was never deleted. Using antiresource/jar locking made no difference.
You need to turn off autoDeploy. If Tomcat detects that a war or dir has been deleted and autoDeploy="true" it will undeploy (ie delete) all the associated resources, including the context.xml file.