>Please reply - this is an important change ! Sure
>I would like to add another configuration mechanism for jk2. >If people agree, this should be the default. > >Assumptions: >- All webapplication that will be served must be >deployed on the machine running the web server ( >otherwise the server can't find the static files ) Caution, caution with security. On many sites, the web-server is located on a DMZ so subject to be hacked, while the Tomcats are behind firewall. Having webapp (program) could raise many problems. INTERNET ---> FW ---> APACHE HTTP -> FW (only ajp13) -> TOMCAT's Why not imagine that Apache will ask to Tomcat, may be to a tomcat tagged a master repository, to be send all the WEBAPPS infs ? >- It is possible you run a load-balanced server and >you may ( or not ) have tomcats on the server machine. Sure a common case, refer to security upper : >- Minimal user configuration for 'simple' case. >Advanced users will still have full power to override. > >Details: >Via workers.properties ( or httpd.conf ) we'llspecify the path >to webapps/ >directory ( one or many ) and the 'style' ( flat or vhost ). > >mod_jk will use the same logic as tomcat to find all subdirs, >and automatically add the contexts. ( using 'global' mappings ) Why not, I'll be more than happy to remove workers.properties and have it included in httpd.conf. Good things will be to map VirtualHost to remote Virtual on Tomcat. >In addition, for each webapplication jk will check > [appbase]/WEB-INF/jkmappings.properties >If the file exists, it'll contain per/webapp mappings >( without the context prefix ) == an easy to parse >form of what's in web.xml. Interesting idea. >In addition, > [appbase]/WEB-INF/jk.workers >will include the list with all tomcat instances where the >webapp is running. If none is found, the default worker >will be used. > >Note: >1. if WEB-INF/jk.workers contains a single worker, we'll >have the current effect of JkMount > >2. If it has multiple workers, it'll be load balanced, >as if a lb worker would have been defined and the app >would be mapped to that worker. > >Benefits: >- Simple things are simple. After the initial configuration >of apache ( consisting of a LoadModule and pointing to >the path to tomcat -- which can be fixed for RPMs or >installed case ), the user will not have to do anything >else but soft-restart the web server. > >- Keep application config separated. > >- The use can still override whatever he wants ( using >explicit configs ) or place apps in different directories. > >- no need to have tomcat running ( or running on >the server machine ) For security reason, i'd like to avoid having webapp code (servlet/jsp) on the web-server. And if tomcat is not running (locally or remotly), did there is a need to do a collect of webapp ? Could we discuss about a Tomcat 3.3 running as a webapp repositories manager ? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
