This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Our Web Application is required to display hyperlinks to external files that reside outside the web application based on certain business rules. The users could then download these large PDF files.
We went ahead with the idea of symbolic links supported by Tomcat.
<Context path="/powerApp" allowLinking="true"/>
We deployed the application and created a symbolic link under the web application directory to point to another external directory on the same server. All the hyperlinks use the symbolic link.
The Application worked Ok. When we undeploy the application, Tomcat seems to be deleting the war file, the exploded directory and also all
the external files that are present in the directory pointed to by the symbolic link!
I was expecting tomcat to delete only the war file, the exploded directory including the symbolic link, but not the external PDF files during an undeployment!
I googled on the net and found that this behaviour has been observed on both Tomcat 5.x and Tomcat 6.x but no proper explanation to this issue.
I was wondering if this is the expected behaviour of Tomcat in this scenario or is it a bug?
It's probably just doing a "brute-force" delete of the directory tree.
Actually, linking is a little dangerous even without Java, Tomcat &co. My own recommendation is to let the webapp reference the external files directly and explicitly, rather than via a soft or hard link. I put their root paths into JNDI variables so I can retarget them at need.
From the sound of it, you're attempting to use Tomcat like it's a file server. Web servers make lousy file servers - they're not designed for that purpose, no matter how much a filesystem path and a URL might resemble each other. Web servers lack key abilities of file servers and vice versa.
There's nothing wrong with using a web server to make files available in places where file servers can't make them available, but you'll have less trouble overall if you don't take the quick-and-dirty solution.
An IDE is no substitute for an Intelligent Developer.
Joined: Aug 27, 2003
thanks Tim for the useful comments,
We moved away from the softlinks approach and have written code to serve the files directly in the servlet now. This seems to work fine on both windows and unix envs.