Oh, that's horrible.
This mechanism is a flaunting of the concept that J(2)EE web applications should be self-contained. That is, all of the resources are located within a single WAR.
Historically, if you really needed to cheat on that idea (say, in order to share the same static content between one or more Tomcat apps and/or other servers such as Apache), you'd patch the deployed WAR to use a symlink and make sure that Tomcat was configured to allow symlink usage (by default, it isn't, for security reasons).
Apparently some people got creative in Tomcat 7 and added stuff like "aliases".
By Tomcat 8, they realized that they'd opened a can of worms and attempted to make it less of a hack, using Resources. For details:
https://tomcat.apache.org/migration-8.html
Essentially, if you MUST use this feature, you'd need to map a physical location to a webapp's logical location, much as the Apache server's Alias command does. In the simplest case, that means defining a "base" attribute and a "webappMount" attribute. If I'm reading things properly, you need to do that on a "PreResources" sub-element to a Context's Resources element.
Unless you've got a really compelling reason, however, I don't recommend doing this. It's tying your application to not only being Tomcat-specific, but also requires extra care in the setup of the server and deployment information. Better to simply make the WAR self-sufficient if you can, either by putting the resources in the WAR itself or in the case of static content, by using URLs that pull from a master static content server.