Angus Mezick wrote:
-----Original Message-----
From: Jess Holle [mailto:[EMAIL PROTECTED]
Mladen Turk wrote:
-----Original Message-----
From: Bill Barker
Having the option to do per-host and even per-context configs
makes life much easier for admins of servers that support it.
Otherwise, you end up with a file that looks like:
<jk-config>
&host1;
&host2;
&host3;
</jk-config>
which is fine for xml-hackers, but not very helpful for
server-admins.
Yes, that's true, but that same layz admin still has to make
the Tomcat
running, or not?
It still has to learn that server.xml stuff, and even make
it working :)
Who ever asked the poor apache admin about the TC's config ater all?
It really does not matter who the admin is. Even a
sophisticated admin
is going to want to have file modification dates they can trust on
various aspects of the configuration so they can answer "did I change
this part?" questions.
Using a modular multi-XML-file approach does not pollute the
result with
any additional server-specific or Tomcat-specific baggage. It just
makes management and automated configuration/installation much more
workable.
Really off topic, but a sophisticated admin should have all of there
configs versioned in CVS and have a script (ant?) that stops the server,
deploys the config, starts the sever.
Should, but most admins don't go that far, unfortunately. [Selfishly I
want the modification dates to remain faithful so that I can look over
such administrator's shoulders and say "look you touched the following 3
.conf files since things were working as desired -- focus on those".]
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
