> If there's a desire to move ahead with a new connector at the tomcat > project, and the branch/release approach is planned to yield stable > code that will improve from release to release, why even retain the > association to 'jk'? It seems it would benefit the effort if stable > code was released with a new module name that could grow to become > trustworthy in user's/adopter's minds.
Hi Bill, The initial discussion was about branching current jk to jk_1.2 and use the trunk to add new functionnalities (a sort jk-1.3-dev). There is today many way to link Apache HTTP to Tomcat : - mod_proxy - mod_proxy / ajp_proxy - mod_jk A new connector appear, mod_cluster with great features. mod_jk is not a 'regular' Apache HTTPd module, since it could be used with IIS, Domino, iPlanet and got JNI support. And so the #define, #ifdef, #whatever to handle various web server, os, compilers It allways was boring and more today with the general availability of APR. So the idea could be to put the AJP support code (networking, clustering, routing) in an external library/API. This library/API could be then used by : Apache HTTPd module implementation, IIS filter or third-party applications (ie: BigXX frontends) could use this library. We could get simpler httpd module (may be even included in the core Apache httpd distribution). Comments welcome --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
