> On the other hand, it should be noted that mod_jk has substantial deficiencies.
> Like mod_jserv before it, this connector is substantially limited -- it requires
> users to double-configure many of the key attributes of a web application
> (security, mapping URIs to particular handlers, MIME-type-mappings, and so on)
> because it does not leverage the configuration informatino available in a web
> application deployment descriptor.
>
> The Apache connector called "mod_webapp" that was included in Tomcat 4.0
> milestone 5 addresses these issues. Pier can give you more details, but it
> should be very amenable to the Apache 2.0 infrastructure. I would not
> personally spend any time trying to make mod_jk or mod_jserv work in a 2.0
> environment, when the future is clearly in a different direction.
Since I believe in a different future and direction, I'll spend the
time to make mod_jk and tomcat3.2 ( and the future 3.3 ) work with
Apache2.0.
mod_webapp is a nice start and I would love to see it integrated with
mod_jk and tomcat3.3, and the autoconfiguration can certainly be reused in
mod_jk - in addition with the current mechanism.
And of course, after mod_webapp is ready we can find out if the current
idea of using the native server configuration mechanisms is good or
bad ( maybe with real technical arguments ). - but the big advantage
in mod_jk and tomcat3.x is that it has the choice of using whatever is
best - for example mod_jserv is still a good adapter from many points of
view - and will continue to be supported next to mod_jk. If you believe
that in "one size fits all" - I'm fine with that, and I have nothing
against supporting that size too.
Costin
