Craig R. McClanahan wrote: > >>I cannot fathom how they plan to do that, since it would violate the >>view of a "web application" as a sealed component on the "servlet >>container". I mean suppose you have a WELCOME.GIF file in your web >>application, how is Apache supposed to serve it, other than through >>WARP? Pre-caching of all static content upon "Warp Deployment"? > > The original design goal was to make a decision based on the incoming > request URI of each request, by asking the following questions: > * Is this request URI matched by a filter mapping? > * Is this request URI matched by a servlet mapping? > * Is this request URI matched by a security constraint? > If the answer to any of these questions is YES, the request must be served > by Tomcat, to maintain the semantics required by the servlet > specification. > > On the other hand, if the answer to all of these questions is NO, there is > no semantic problem with allowing Apache to serve this resource, instead > of the default file-serving servlet in Tomcat.
So, there is only one bit unclear to me. How was Apache supposed to serve it? Basically, my webapp directory is not within Apache's DocumentRoot. Is Apache going to cache the static content or what? >>Or perhaps, not pre-caching, but just simple caching? Man, that is >>dangerous. Suppose I keep my GIFs in database and I upload new GIFs. OK, >>OK, perhaps it is not a good idea to remap *.gif to a servlet, since >>browsers might cache it, too. > > If you remap "*.gif" to a servlet, the request would always be served by > Tomcat, in accordance with the rules above. Yes. > Uploading new GIFs, and expecting them to be served, would "violate the > view of a 'web application' as a sealed component on the 'servlet > container'" :-). Indeed. :-) >>Anyway, a web application with a whole lot of static content might need >>some re-modeling? > > I don't see why. Why is it a "web application" if it has a lot of static content in it? Let Apache be burdened with static part of your presentation and keep truly dynamic parts as web apps. > Still the case, as far as I know. (BTW, that's also the answer to your > question about why mod_webapp isn't done yet). Sad to hear that. Nix. -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
