On 19 September 2012 23:58, Christopher Schultz
ch...@christopherschultz.net wrote:
-BEGIN PGP SIGNED MESSAGE-
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
catalina.properties 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 catalina.properties, 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.
+1
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 catalina.properties.
(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 catalina.properties).
(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
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
iEYEARECAAYFAlBaTi8ACgkQ9CaO5/Lv0PDpaACeNNxBsU4it2CXaxdpNp/5x5n+
5KQAnA0l0i07nPgYTUBOkfsa5VF4EWYH
=uuLR
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
--
Best Regards,
Brett Delle Grazie
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
