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
