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
