Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Message-ID: <40FD45A6.30501@apache.org>
Date: Tue, 20 Jul 2004 18:17:42 +0200
From: Henri Gomez <hgomez@apache.org>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
MIME-Version: 1.0
To: dev@httpd.apache.org
CC: Guenter Knauf <eflash@gmx.net>
Subject: Re: Invitation to HTTPD commiters in tomcat-dev
References: <30C025BBA30D3343935890628BCCEA32AEDD73@BOSEXVS2.digitas.com>
 <40FD446B.2080502@sharp.fm>
In-Reply-To: <40FD446B.2080502@sharp.fm>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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.

Regards