tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bojan Smojver <bo...@binarix.com>
Subject Re: JK2: Configuration(1)
Date Fri, 07 Dec 2001 09:01:03 GMT
costinm@covalent.net 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:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message