To clarify - this is not a replacement or an 'exclusive' mechanism. The 'ajp14' based config, where tomcat sends notifications to apache remains.
The problems with 'tomcat sending config info to apache' ( and why I would not make that the 'default' simple config ): 1. It requires a strict startup sequence ( tomcat before apache ). Otherwise, if tomcat is not started apache will respond '404' for what it doesn't recognize, instead of 'temporary unavailable' or 'context is down'. This can be very problematic for users ( who'll assume the url is wrong instead of try again later ). 2. Apache ( or server ) configs will be located on the server machine anyway. I prefer keeping it centralized, and maybe have a mechanism to rsync the webapps directory from the master to the workers instead of reverse. 3. Regarding security, I believe tomcat may be as vulnerable. Apache is serving static files ( assuming a java shop ), tomcat is running potentially insecure code. Of course, sandbox can help, but it's not that easy to use with real-world applications. It's way too easy to write a servlet that uploads a file and doesn't check very well the directory. So keeping tomcat inside the firewall may not be the best idea ( after all most apache exploits I know are related with the dynamic code it runs ). Unless you run sandboxed tomcat. Costin On Fri, 7 Dec 2001, Bojan Smojver wrote: > [EMAIL PROTECTED] wrote: > > > > Please reply - this is an important change ! > > > > 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 ) > > I'm not sure why the whole app has to be on the same machine. You could > have static files on one box and Tomcat with its set of files on > another. In this case you'd have to double deploy or something... Why > not just point mod_jk to the host running Tomcat and then they can > figure out the rest (more below). > > > - It is possible you run a load-balanced server and > > you may ( or not ) have tomcats on the server machine. > > > > - 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 ). > > I'd specify hosts where Tomcat runs instead. Default localhost. > > > mod_jk will use the same logic as tomcat to find all subdirs, > > and automatically add the contexts. ( using 'global' mappings ) > > I'd actually do that in Tomcat and 'serve' it to mod_jk upon first > connection, so that mod_jk has the opportunity to configure itself. This > would avoid double deployment and would also mean that webapps directory > would still be read through Java only (much easier then C). > > > 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. > > Again, why teach mod_jk all that when Tomcat knows how to do it already. > Just pass it back to mod_jk on the first connect together with other > context info. > > > 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. > > This would be preserved in my scenario but it would not cause double > deployment in case of split Apache and Tomcat machines. Configuration > would be done at first connect from mod_jk to Tomcat. > > > - Keep application config separated. > > Yep. > > > - The use can still override whatever he wants ( using > > explicit configs ) or place apps in different directories. > > By all means. > > > - no need to have tomcat running ( or running on > > the server machine ) > > Yes. Furthermore, unless Tomcat is actually running somewhere, there is > no need to configure mod_jk at all. Similarly, when config in Tomcat > gets changed, mod_jk can be notified automatically to reconfigure > itself, in the scenario I'm proposing. So, it makes it even more > flexible. > > Bojan > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
