Thanks Ingo, Chris, Out of curiosity, I had tried the fake Application or fake docBases root approach mentioned by Ingo. It worked for me on Tomcat 5.5.17 and Windows XP.
My fakeApp.xml (context.xml) was : <Context docBase="C:\\temp\\fakeApp" path="/fakeApp"/> I copied this into the directory: TOMCAT_DIR/conf/Catalina/localhost C:\\temp\\fakeApp is the directory containing the list of external PDF files that need to be served to the users. I had also created a WEB-INF directory with a web.xml file here. My main web application had a page containing the href links to the external files that need to be downloaded to the user. <a href="/fakeApp/test.pdf">test.pdf</a> This approach seems to work. Upon undeployment of fakeApp using Tomcat Manager, only the fakeApp.xml was deleted from the TOMCAT_DIR/conf/Catalina/localhost directory. The directory and all the files under C:\\temp\\fakeApp remained intact. (unlike in the soft links approach!) I did not bother testing on Unix, as I think it is quite likely to work on Unix also. The fake document base approach seems to be better than the soft links approach, (atleast it did not delete all the external files!) The disadvantage that I see is the loss of Security. Since it appears to be a seperate application, the security that is available in the original Application is not carried forward to the fake Application. Anybody who knows the direct URL to the fake Application can download the external files. In the end, we decided to write file-serving code ourselves in our servlet, in our original application. The directory containing the external PDF files, is located outside the $TOMCAT directory, is a configurable parameter to the web application. A few more lines of code...it doesn't look too bad! :)- --- On Fri, 12/18/09, Ingo Gambin <igam...@brilliant.de> wrote: > From: Ingo Gambin <igam...@brilliant.de> > Subject: Re: Tomcat 5.5.17 - allowLinking property - symbolic links > To: "Tomcat Users List" <users@tomcat.apache.org> > Date: Friday, December 18, 2009, 10:10 AM > Hehe, > > this I learned only a few days ago. I hope you didn't loose > valuable > information. > > But yes, this is the expected behaviour. > > In order to solve the problem you just have to add 'fake' > docBases ... > see below in the answers I got from Chris. > > Although i have to add, that adding the <Context...> > directive to > > conf/Catalina/localhost/<name>.xml > did not work for me on Tomcat 5.5. > > Putting it into server.xml on the other hand worked > perfectly. > > Best regards, > > Ingo > > Am Freitag, den 18.12.2009, 02:01 -0800 schrieb Vishwa. K: > > Tomcat 5.5.17 > > Solaris 5.10 > > > > 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 fine. 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? > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
