httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: Invitation to HTTPD commiters in tomcat-dev
Date Tue, 20 Jul 2004 16:12:27 GMT
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 

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.


View raw message