Jan Jonas wrote: > Hi everybody, > > I have the following problem: I have a web application that is deployed in a > war files. This web application serves a lot of static content files (the > users are able to upload the content (html, imgages ...)). Obviously it is > not meaningful to pack the user's content in the war file, because the > content is user generated and an update of the application should not touch > these files. Moreover the delivery of the content is restricted: You can only > download the content if you are logged in. > > My current approach is as follows: The content is stored in a directory > outside the docBase of the application and a servlet is used to check the > session, read the files from the file system and deliver it to the client. In > this servlet I'm handling with file streams and set the http headers (like > "content-type", "Last-modified" ...) manually which is ugly in my eyes. > > My Questions are: > > - Is there an elegant way to server files that are not stored in the > webapps directory (something like a RequestDispatcher for files in the file > system)? > > - Is there a way to protect a directory from being overridden when > deploying the war file? This directory then could be used to store the > content and a filter could check the session.
How adventurous are your feeling? Tomcat 7 (still in development) can do this (apart from the upload - but you could easily do that with webdav) out of the box just with configuration. From the Context element docs in Tomcat 7: <quote> <attribute name="aliases" required="false"> <p>This attribute provides a list of external locations from which to load resources for this context. These external locations will not be emptied if the context is un-deployed. The list of aliases should be of the form <code>"/aliasPath1=docBase1,/aliasPath2=docBase2"</code> where <code>aliasPathN</code> must include a leading '/' and <code>docBaseN</code> must be an absolute path to either a .war file or a directory.</p> </attribute> </quote> It is very much still in the pre-alpha phase but mainly because there is still a lot of the Servlet 3 features to implement. Most of the code is identical to that in Tomcat 6. If you wanted to to try it, you'd get the feature you are looking for and the developers would get some useful feedback on any bugs. You'd have to built Tomcat 7 from source (not hard) and you wouldn't be using an official ASF release. WDYT? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
