On Wed, 15 Aug 2001, Mike Anderson wrote:
> The problem with this is that when you start tomcat outside of Apache,
> it isn't really doing anything but generating the auto-config files. They
> whole idea of the JNI connector is that the web server starts its own
> version of Tomcat by instantiating a JVM inprocess. Even if you have
> an external Tomcat process running, the webserver wouldn't be talking
> to that one via JNI. This also means that you basically have to kill the
> Tomcat process that you start up by hand, plus, when Apache starts up
> it's version of Tomcat, it would probably overwrite the auto-config file as
> it came up which might cause some additional headaches.
The "auto-config" files are intended to avoid manual configuration - we
have web.xml, and we can generate the informations about the mappings.
That's how ajp12, ajp13 work.
Ajp14 can work without this ( AFAIK mod_webapp still requires to manually
add each web application ). But in this mode there are serious
reasons to believe we'll affect the performance ( except maybe Apache2.0
where it seems to be possible to alter the server config at runtime ).
This is a long-term discussion, not important for the current release, but
we should keep it in mind :-)
IMHO generating config files is not going to go away, even in 1.4, as it
provides extremely important benefits - it gives the user a chance to
"fine tune" the process ( which is extremely difficult when the config is
sent over the wire ). And it's faster, as it doesn't duplicate the mapping
stage ( and uses the server mapper, probably better than jk's ).
Now the question is how do we want to deal with this configuration mode.
For most users it will not matter after ajp14, since
automatic-over-the-wire will cover most common cases. For advanced users -
it will matter.
My proposal ( quite simple to code ):
- add a "-serverconf XXX" to tomcat.sh. ( trivial ). It'll set XXX as a
ContextManager note/attribute.
- uncomment <ApacheConfig/>, <IISConfig>, etc in server.xml, and alter the
modules to do nothing unless "serverconf" note matches. ( XXX==apache to
generate apache configs, etc ). That means - no server.xml changes for
common use.
- starting tomcat will not generate any configs.
- running "tomcat -serverconf apache" will generate the configs for
apache. Alternative: a new script "confgen.sh apache" that will just
generate the scripts.
The new rules:
- install the DLLs.
- run "confgen"
- start apache.
Long term, the confgen.sh can do few other things, like insert the
"Include" in httpd.conf, etc.
IMHO it's a decent solution.
The user must expect that in order to deploy/undeploy webapps ( or change
configs ), they must run something to let the server know about it. Or we
can detect that and run "confgen" from tomcat. There are many choices and
ways to improve if we go this path.
What do you think ?
Costin
