-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tobias,
On 11/30/2009 1:30 PM, Tobias Crefeld wrote: > Am Mon, 30 Nov 2009 08:02:41 -0800 (PST) > schrieb Thomas Moorer <tcm...@yahoo.com>: > >> I have been thinking about upgrading my Tomcat 6.0.16 >> instance to the latest 6.0.20. I have been thinking about the best way >> to do that. I have modified several config and shell files and suppose >> I could just copy those to the 6.0.20 instance, but then I began to >> wonder if I could just update the Tomcat specific files in my current >> install location. > > Usually (!) it should be enough if you copy the files from conf/ and > bin/ (and your application, of course) to the new apache-tomcat-tree. That's a great way to a) downgrade your install or b) destroy your install. Let's see what's in the bin/ directory of a standard Tomcat install: 1. bootstrap.jar - Looks important! Should you really clobber this? 2. tomcat-*.jar - Same here! 3. tomcat6*.exe - Hope there aren't any bugs in the old version! 4. *.sh / *.bat - Same here! This may sound silly until you realize that even the shell scripts are updated across minor versions sometimes. There was a bug where setting the logger via a system property resulted in a mangled command-line that failed to properly launch the JVM. This was fixed with a tweak to the shell script that starts Tomcat. If you copied that script from your old installation, you'd be "upgrading" in the sense that a lot of the code would be new, but the scripts would still be broken, along with everything else. The only thing in bin/ that it's safe to blindly copy to a new Tomcat install is bin/setenv.sh (or bin\setenv.bat) and that's because Tomcat does not come packaged with such a file. > It depends on how "clean" your installation is. If you have put > additional jars into the apache-tomcat/lib/ - directory in the past > this might be the better way. Of course this isn't good practice > because application specific jars should be installed unter > webapps/<application>/WEB-INF/lib/. The exception to this rule is, of course, JDBC drivers. I'm sure there are other examples as well. > Running Unix/Linux I prefer another practice. In the home-dir of the > tomcat-"User" I create a skeleton similar to the following: > > ~/tomcat ... OMG are you a Linux distro package maintainer? > After this preparation changing to another tomcat-version is just a > deletion and re-creation of the symbolic link "default" > ( ~/tomcat/default -> /opt/apache-tomcat-6.0.20 ) and you roll back > to an older version the same way. There is a much easier way: use the CATALINA_BASE environment variable. > Maybe this principle works under MS-Windows as well. I read that MS is > offering symbolic links since WinXP-SP2 but I have not much experience > with their OS. Such tricks are unnecessary if you use the ingenious mechanism provided (and preferred) by the Tomcat devs. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksUJOgACgkQ9CaO5/Lv0PC6hwCfaJrD/fBgupdXaYyXchFnVMlk xIgAn1FtYOpQp/XbDlLDpY+5l558sO36 =lsW/ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
