On Sat, 8 Dec 2001, Bojan Smojver wrote: > [EMAIL PROTECTED] wrote: > > > > To clarify - this is not a replacement or an 'exclusive' mechanism. > > The 'ajp14' based config, where tomcat sends notifications to apache > > remains. > > Seems like I was reinventing the wheel there for a while. So AJP14 knows > how configure itself from the running Tomcat... Pretty cool in my book!
Yes, Henri has added quite a bit of code for that. I did few changes to make the 'autoconf' usable with other workers and more 'exposed' - see jk_webapp, jk_uriEnv. And this will remain and will be enhanced - we want tomcat to be able to send notifications like 'webapp reload' or 'webapp down', etc. Or the reverse - apache to send this to the workers in the farm ( assuming a 'central' tomcat or after a soft restart of apache ). The major problems and why I don't think this can be the only way: - it requires tomcat to be started - it's not very clear how it'll work for a complex case ( many workers, some apps replicated, some not ). It's hard to imagine how to do that in general, having it automated and on the wire is too much. - it's hard to 'tune'. I think we are at an early stage, where we still learn how people are using tomcat/apache. With few scripts you can do a lot - like rsync webapps/, generate 'native' configs, insert special settings. > > 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 ). > > This is easily achieved (that's how I run my boxes) through the startup > script when both Apache and Tomcat are on the same box. I call this > thing 'was' -> Web Application Server. Here is the sample (RH Linux > 7.0): On a complex site, Apache will probably server more that java pages - and talk with more than a single tomcat. Having a file-hierarchy based system can allow delegation ( change the permissions on a dir and let a group manage an application/vhosts ), etc. Things that would be hard to do if we rely only on a wire protocol ( or at least hard to do in the next 2-3 months, after we gain more experience I'm sure we can do it ) Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
