First, a
web server is
not a file server. So you cannot just plunk down files and expect them to behave like they would on a file server.
Web servers serve
web applications. A web application is expected to be self-contained, with all of its local resources in its WAR, which according to
J2EE and JEE specs is a JAR file, although many servers - including Tomcat - allow the WAR to be unzipped into an equivalent set of directories and files (a so-called "exploded" WAR). The default arrangement in Tomcat is that any directory directly under TOMCAT_HOME/webapps is expected to be the root of a WAR with a corresponding URL context path equal to that directory's name. WARS (and therefore webapps) are all first-class objects - no WAR may contain another WAR either physically or logically.
So, unless you exploit OS-specific hacks, unusual Tomcat settings and other discouraged practices, there are only 2 ways to get multiple webapps to share any static resource.
The first way is brute force, where you simply include a copy of the resource in each WAR that you deploy.
The second way is to create a separate webapp specifically to hold that resource (and possibly other shared resources as well), and code the other webapps to reference the URL path of the resource within that webapp. Of course, since this is a separate webapp, you don't even actually have to use Tomcat to serve up that shared static resource - you could just as easily have an independent high-performance server (such as Apache httpd or Nginx) serve up that resource. This is basically what any webapp that uses something like jQuery does if it references the master jQuery URL instead of copying the jQuery javascript files directly into the webapp that uses them. And, of course, the global jQuery URL is pulling from an external server.
Note that while taking the second approach breaks the self-containedness of a strict J2EE webapp, you gain several advantages by using it. Not only do you have smaller referencing webapps and a one-stop update point for any modifications to that resource, but you can set client caching options so that the user's client keeps a single shared copy instead of making a separate copy for each webapp.