First, I have to issue the customary warning that a WEB server is not a file server. So when you use a url like http://localhost:8080/temp_mp3/02_Queen_Radio%20Ga%20Ga_14855533586894.mp3, you're not getting something that the client can do a "file open/read/close" operation on, instead the webapp's WAR resources are queried to find something mapped to the WAR path "/temp_mp3/02_Queen_Radio%20Ga%20Ga_14855533586894.mp3", which the webapp server will copy to the HTTP response output for the client to send to a local app or save (depending on the client configuration).
In the course of normal events, then, attempting to retrieve a file from a directory outside of the WAR wouldn't be possible. What you'd have to do is create a servlet mapped to the WAR resource path '/temp_mp3' and code that servlet to look in directory c:\temp_mp3\ for the requested mp3., which it would then open and copy to the HttpResponse stream.
Tomcat does have a limited ability to simplify that, although it requires relaxing the normal security configuration. In such a case, you'd have to unzip (explode) the WAR to a directory (actually this is default for Tomcat), then create a soft-link from the WAR's /temp_mp3 resource path to C:\temp_mp3. PLUS you have to change the normal security constraints in the TOMCAT_HOME/conf/server.xml file to allow Tomcat to follow softlinks. That would allow the particular resource organization that you say you want.
When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.
It's just like a fortune cookie, but instead of a cookie, it's pie. And we'll call it ... tiny ad:
global solutions you can do at home or in your backyard