> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 15, 2001 1:20 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Native configuration changes.
>
>
> 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 ?
I'm fine with this as long as there is a simple way to have
ApacheConfig, IISConfig, etc. always write the auto-generated files.
If I'm running Tomcat out-of-process, I'd prefer to simply
start Tomcat first and then Apache to pick up configuration changes.
>
> Costin
>
>
