httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Gomez <>
Subject Re: Invitation to HTTPD commiters in tomcat-dev
Date Tue, 20 Jul 2004 16:17:42 GMT
Graham Leggett wrote:

> Manni Wood wrote:
>> The real trick is getting Apache to serve all of the static content, and
>> getting tomcat to deal with only servlets and jsps.
> As has been pointed out, mod_rewrite can do this already.
>> I notice in all of the documentation I find for mod_jk, an entire
>> directory (/examples/* being everyone's favourite) is mapped to Tomcat,
>> so that even requests for images are passed back to tomcat, rather than
>> being taken care of Apache directly.
> Most of the time "simple is better". It is only if you have serious 
> loading problems that you would want Apache to take over the static 
> load, or if you have an extraordinarily high number of static files to 
> serve.
> Especially for a new user, they want to get from "nothing" to "basically 
> working" in as few steps as possible. Getting it from "basically 
> working" to "working as fast as possible" is a separate exercise.
> I fully agree that having Apache able to serve static content can be 
> very useful in many situations, but I don't think it need apply in the 
> default case.
>> For business sites where the entire web site is the webapp (/* in other
>> words) apache is just passing *everything* back to tomcat, which pretty
>> much makes one give up and serve the whole site using Tomcat, forgoing
>> some of Apache's nicer features that have not yet been implemented in
>> tomcat (such as mod_usertrack.)
> Remember that in Apache v2.0 most of the modules like mod_usertrack are 
> implemented as filters.
> This means that you can add mod_usertrack to the frontend, and use it 
> regardless of where the actual response came from (tomcat via ajp or 
> proxy, a static file on disk, whatever).
> It's very useful when you have a site with multiple sources of 
> responses, and you want certain things to work across the board.
>> So I must stick to my argument here, and say that finding truly good
>> documentation for mod_jk, for fine-tuned configuration, as required by
>> the many business clients I've done work for, is difficult to impossible
>> at this point in time.
> This I agree with, but the fix here is to improve the docs, rather than 
> change the code.

Well jk/jk2 didn't works well every time with others modules since for 
example they handle some URIs themself, so appears problems with 
Alias/Directory/Files/UserDir and so on ;(

The documentation is a good thing, a rewrite of the code based on APR
(no more tons of defines to handle all os by hands), and a design
focused on Apache 2.x will be the final solution.

And in fine if we could have proxy_ajp included in Apache 2.x
distribution, we'll a great step in Apache2/Tomcat integration,
which should be a goal for ASF members we are.


View raw message