Hi all servlet gurus, I have found something in Tomcat (the servlet API) that, at least I myself, find really unbearable, namely, the webapp context constraints not letting you have a central directory to serve static files, css, etc's ... After searching the web it really amazes me that this isn't apparently "an issue". How could you propose enhancements for the Servlet 2.4 API? Catalina (the servlet reference implementation) has the org.apache.catalina.servlets.DefaultServlet taking care of these types of problems (so it was apparently seen as an issue by the designers of the servlet engine). Why not making it standard in the Servlet API? Please, let me know if there are high flying concepts I don't know/am not taking into account here. Thanks // - - - - - - - THREAD - - - - - - I was having problems forwarding requests and serving static files (images, css) with TOmcat using servlets. Apparently the "web context" thing from the servlet specification is doing some damage here or there is something I don't get right. Do you have to set up the same directories with the same static files in all webapps?!?!? As a matter of fact I checked TCs webapps and the exact same file, e.g., tomcat.gif, in four directories. How do you deal with that? How could you set up a central <TOMCAT_HOME>/images/ directory readable to all served pages from different web contexts? // - - - - - - - REPLY I GOT FROM comp.lang.java.programmer - - - Message 2 in thread From: Ryan Breidenbach (firstname.lastname@example.org) Subject: Re: repeated static files with TOMCAT? Newsgroups: comp.lang.java.programmer View this article only Date: 2002-10-02 05:49:53 PST
Don't think you can do this, AFAIK. What you can do is register and "ImageServlet" that is configured to serve images from a configurable directory. This directory could be passed to the servlet as an initialization parameter. Then, for each webapp, you register this servlet for any *.gif or *.jpg request. To see how so write a file-serving servlet, take a look at Catalina's DefaultServlet (I think that's the servlet Tomcat uses to serve files). Hope this helps. Ryan // - - - - - - - - - - - - MY REPLY/IDEA/(REQUEST?) Then I think there is something wrong with the Servlet 2.3 spex. The thing is that I will have to serve many different types of images, stylesheets, etc. based on the user agent Am I the only one having problems with this? I think a nice solution would be declaring in <TOMCAT_HOME>/conf/server.xml something like: <!ELEMENT static-resources (resource*)> <!ELEMENT resource (local-path+, local-path-subs?, resource-name?, description?)> <static-resources> <resource> <local-path>/images/gifs/</local-path> <local-path-subs /> </resource> <resource> <local-path>/images/png/</local-path> <resource-name>pussycat.png</resource-name> </resource> <resource> <description>User Agent dependent css go in here</description> <local-path>/css/</local-path> <resource-name>*.css</resource-name> </resource> <static-resources> With the following semantics: static-resources: branching tag resource: to declare each of the resources local-path: local path from <TOMCAT_HOME> up local-path-subs: flagging if static files in subdirectories should be treated the same way resource-name: file name of the static resource, accepting wild cards as in "*.css"
If I understand what you are saying, it is contrary to Sun's idea of a "Web Application" which is completely independent of all other Web Applications running on the same servlet engine. This concept is essential to the commercial sale of web applications so I don't think you are going to get anywhere. Bill
OK, but how do other people deal with it? Say you are dealing with lots of pictures that are essentially repeated for many web-apps, would you maintain all these pictures in all these directories/web-app contexts?
AFAIK that the same 'PROBLEM' is with the custom tags and other stuff like struts. We have to copy the tld file for each web-application...so what if i need to SHARE the same library or stuff again and again for different webapps? Comments?
I know only one thing, that i don't know anything !!