Welcome to the JavaRanch, Thomas.
Tomcat is not a file server. It's a web application server. A web server accepts URLs and routes them to be processed. The default processor will convert the URL to a relative pathname, attempt to locate a resource at that path location, and, if it finds one, copy the contents of that resource to the response output stream going back to the user's browser. Subject to the restriction that /WEB-INF and its children cannot be copied.
According to the strict
J2EE specification, a WAR isn't even a filesystem directory tree at all. It's a JAR (ZIP) file. However many appservers - including Tomcat - can explode the WAR into a designated directory or reference a pre-exploded WAR directory.
In practical terms, however, if you're careful, you can bend the J2EE standard to do what you want if your operating system is capable. This requires that you create a symbolic link in your exploded WAR to the external directory
and it requires that you configure Tomcat to allow it to lookup resources through symbolic links. That feature is turned off by default because it's a security risk.
This approach works, but has various flaws. As mentioned, your OS has to support symbolic links, symbolic links mean a security risk. Plus a true WAR doesn't have any way to indicate symbolic links. A cleaner approach requires writing (or stealing) a simple file-copy
servlet. All the servlet does is convert a URL to a filename path and copy the contents of the file at that path to the response stream just like the Tomcat default processor does. For more flexibility you can provide the base directory name as a parameter and supply it in your web.xml file, a properties file, JNDI or whatever, so that you can switch to another directory without recompiling - for
testing purposes, for example.
