>> 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.
As usually costin make a remarquable cleaning here :) >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 We could keep a copy of the latest known configuration and fall back to this one if the 'Tomcat Master Repository' is not available at start time. Which make me think that we should add some mecanism to let a tomcat announce itself when it wake up, not so easy till we have a true multithreading WebServer... >- 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. A simple mecanism could be to for 'at best discovery' in web-server. ie in main or virtual hosts part of httpd.conf (and corresponding IIS/iPlanet) to have a : JkAutoMount * worker (which will means, grab ALL the revelant webapps for this virtualhost instance). >- 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. Sure... >> > 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. Yes, Apache talking with a farm of tomcat using load-balancing mode. But we assume that all tomcat's have the same webapps installed. >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 ) Yes, let's put jk2 to life quickly, add stuff in protocol, (to be implemented latter). -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
