>I think Dan is right on this one - improving the configuration
>of mod_jk
>is probably the most important thing, and merging with mod_webapp and
>porting it's protocol and config mechanism would be a good way
>to do that.
I agree that integrating mod_webapp functionnalities is not
a priority for the 3.x branch. We could add the autoconf stuff
or may be also use APR which will hide all OS complexity.
The problem today, is that there is 2 version of mod_jk :
*) mod_jk in Tomcat 3.3
Latest code, maintainers, bugs fixed and Apache 1.3/2.0 support
*) mod_jk in Tomcat 3.2.x
The same code since 3.2, no much maintainers, some bugs fixed in 3.3
are not in 3.2, only Apache 1.3 support.
If a user have problem using mod_jk against it's Tomcat 3.2.1
release (or upcoming Tomcat 3.2.2), we'll ask him to use the
mod_jk from Tomcat 3.3 CVS !
Problems could be using Apache 2.0 or Apache restart needed
after Tomcat shutdown/restart when using ajp13, .....
>I think the best way to do that would be a revolution ( like
>jasper34 ),
>and when it's ready propose it as either a replacement for
>both mod_jk and
>mod_webapp, or as a top level project ( if enough people will
>contribute
>on it ). Combining mod_jk and mod_webapp is likely to result
>in something
>better than both, so the vote to replace mod_jk and mod_webapp
>will be a
>formality :-)
I strongly think we must have the connectors in a separate project
so I'll follow your proposal and start a revolution.
>( making it a top level project now is not a good idea right
>now, neither
>to do the development in the main tree - there are just few
>big bugs to be
>fixed before a 3.3 beta. )
Yep, I'll keep maintain the code in 3.3 tree and in parallel
start the proposed revolution :
* native code extracted => connector
* java code moved from tomcat core/utils => org.apache.connector
>P.S. It's fun beeing a "revolutionar" !
Let's go, there were not much revolution from France since 1789....
