On Fri, 18 Jan 2002, Nikola Milutinovic wrote:
> Date: Fri, 18 Jan 2002 10:36:29 +0100
> From: Nikola Milutinovic <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: Tomcat Users List <[EMAIL PROTECTED]>
> 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: <mailto:[EMAIL PROTECTED]>
For additional commands: <mailto:[EMAIL PROTECTED]>
Troubles with the list: <mailto:[EMAIL PROTECTED]>
