tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Delle Grazie <>
Subject Re: Best practices for upgrading Tomcat on Windows?
Date Thu, 20 Sep 2012 10:42:39 GMT
On 19 September 2012 23:58, Christopher Schultz
<> wrote:
> Hash: SHA1
> David,
> On 9/19/12 4:32 PM, David A. Rush wrote:
>> Is there a set of best practices documented anywhere for upgrading
>> Tomcat on Windows? I run Tomcat as a Windows service on several
>> machines.  I can, and have many times, completely removed Tomcat
>> and reinstalled a new version, but there's probably a better way,
>> particular for minor version updates (such as 7.0.x to 7.0.x+n).
>> I've developed a standard way of setting up Tomcat that's used
>> across multiple machines, but it doesn't lend itself well to
>> upgrades.
>> I don't use the "Windows installer", but rather make bulk copies of
>> the Tomcat code and use the "service installer" script, somewhat
>> modified for our peculiarities.
>> For minor version updates, should I be able to stop the Tomcat
>> windows service, copy any customized files such as server.xml and
>> and setenv.bat, copy new code over old code,
>> copy the customized files back, and start the service again?
> There are no hard-and-fast rules for what will and won't change with a
> Tomcat release, even at the minor-revision level. Tomcat itself
> doesn't offer any "upgrade" options -- just separate installs.
> Honestly, I think that works out quite well, since it encourages you
> to install multiple versions side-by-side which makes roll-backs quite
> easy: if the latest version has some bug that scuttles your project,
> you can just uninstall the "upgrade" and go back to business as usual.
> IMO, the best way to "upgrade" Tomcat is to use a "catalina.base"
> which is distinct from "catalina.home". Read the README.txt file that
> comes with Tomcat to see how that's done. Once you are comfortable
> with that, upgrading to a new version of Tomcat is as simple as doing
> a diff between your customized server.xml (and, if
> you end up customizing that for whatever reason) and the new stock
> server.xml from the latest Tomcat and merging-in whatever is new,
> switching the catalina.base parameter to your service and restarting
> Tomcat. Switching back is the opposite procedure.
> I would recommend this technique to anyone using Tomcat, whether they
> are running on Microsoft Windows or not.

In addition if you want to be ultra cautious or you replicate the
install repeatedly:
Store the bin/setenv.(bat|sh) and conf/ directories in some form of
version control
(limit to what is appropriate for your environment)

e.g. I have a 'production base config' which:
(a) Configures Tomcat for logging using logback (including access logs)
(b) Configures Tomcat server.xml to use a specific set of connectors
and specifies the ports via properties in
(c) Configures Tomcat web.xml for production usage (settings as per
Tomcat JSP documentation optimised for production).
(d) Configures the Manager and host applications (via a custom
context.xml) with IP valve and user id's as specified.
(e) Configures JMX so the JMX listener is on a specific set of ports
(specified in
(f) Could potentially configure clustering here in the same way.

A lot of this is likely specific to my environments but it goes a long
way to automating a base setup that is production
ready - yet can still be remotely debugged (with caveats) if
absolutely necessary

> - -chris
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools -
> Comment: Using GnuPG with Mozilla -
> iEYEARECAAYFAlBaTi8ACgkQ9CaO5/Lv0PDpaACeNNxBsU4it2CXaxdpNp/5x5n+
> 5KQAnA0l0i07nPgYTUBOkfsa5VF4EWYH
> =uuLR
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Best Regards,

Brett Delle Grazie

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message