Return-Path: Delivered-To: apmail-jakarta-tomcat-user-archive@apache.org Received: (qmail 10074 invoked from network); 18 Jan 2002 17:54:03 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 18 Jan 2002 17:54:03 -0000 Received: (qmail 16630 invoked by uid 97); 18 Jan 2002 17:52:10 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-user@jakarta.apache.org Received: (qmail 16596 invoked by uid 97); 18 Jan 2002 17:52:10 -0000 Mailing-List: contact tomcat-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Users List" Reply-To: "Tomcat Users List" Delivered-To: mailing list tomcat-user@jakarta.apache.org Received: (qmail 16572 invoked from network); 18 Jan 2002 17:52:09 -0000 Date: Fri, 18 Jan 2002 09:52:06 -0800 (PST) From: "Craig R. McClanahan" To: Tomcat Users List Subject: Re: mod_webapp and php In-Reply-To: <002001c1a003$9bab37c0$0a3ea8c0@ev.co.yu> Message-ID: <20020118094501.L41014-100000@icarus.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Fri, 18 Jan 2002, Nikola Milutinovic wrote: > Date: Fri, 18 Jan 2002 10:36:29 +0100 > From: Nikola Milutinovic > Reply-To: Tomcat Users List > To: Tomcat Users List > Subject: Re: mod_webapp and php > > > Yeah, its interesting question, maybe for Tomcat developers to come up, > > besides its marked as FIXME to add some info about the way mod_webapp > > work behind the scene. :)) > > > > but: > > > > RELEASE-NOTES-4.0-B7.txt > > --------------------- > > Tomcat 4.0 and Apache: > > --------------------- > > > > The binary distribution for Tomcat 4.0 includes the most recent stable version > > of the WARP connector, which is the Tomcat component that talks to mod_webapp > > inside Apache 1.3. The current state of this support is summarized as follows: > > > > * The mod_webapp connector is configured based on the contents of the > > web.xml file for your web application. The only required per-webapp > > configuration information in your Apache 1.3 httpd.conf file is > > something like this: > > > > WebAppDeploy examples warpConnection /examples/ > > > > which causes mod_webapp to automatically recognize all of your servlet > > mappings, security constraints, and other configuration elements. > > > > * Currently, mod_webapp forwards *all* requests under the specified > > context path to Tomcat for processing. When Tomcat 4.0 final is released, > > it will automatically configure itself to serve static resources > > from Apache *unless* the resource is subject to filtering, or subject > > to a security constraint, as defined in web.xml. No extra configuration > > in httpd.conf will be required. > > 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. > 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. 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'" :-). > Anyway, a web application with a whole lot of static content might need > some re-modeling? > I don't see why. > > and: > > > > RELEASE-NOTES-4.1-dev.txt > > --------------------- > > Tomcat 4.0 and Apache: > > --------------------- > > > > The binary distribution for Tomcat 4.0 includes the most recent stable version > > of the WARP connector, which is the Tomcat component that talks to mod_webapp > > inside Apache 1.3. The current state of this support is summarized as follows: > > > > * The mod_webapp connector is configured based on the contents of the > > web.xml file for your web application. See the documentation included > > with the connector for configuration requirements. > > I guess they realized that they cannot even make a promise on that. > > Whatever happened to Pier Fumagalli (if I remeber the name correctly)? > He was the main man behind mod_webapp. Last I heard, he was looking for > a new job. > 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). > Nix. > Craig -- To unsubscribe: For additional commands: Troubles with the list: