how to upgrade tomcat 8.5.x?

Discussion:

m***@comcast.net

2017-05-16 13:37:10 UTC

First-time Tomcat user here. I installed 8.5.9months ago, and would like to upgrade to the latest 8.5.15. I see there's some documentation for updating the 8.5.x branch here,

http://tomcat.apache.org/migration-85.html#Upgrading_8.5.x

but I'm missing some context. I have a fairly simple install/application, and wonder what the conventional wisdom is how to perform the update.

I assume I need to shutdown Tomcat. Then, is there a set of directories I should just replace to perform the update? Are these directories listed somewhere? Then do I just restart Tomcat to finalize the update? Any advice much appreciated (the more specific the better). Thanks in advance, Gerry

Igal @ Lucee.org

2017-05-16 14:43:36 UTC

Permalink

Post by m***@comcast.net
I assume I need to shutdown Tomcat. Then, is there a set of directories I should just replace to perform the update? Are these directories listed somewhere? Then do I just restart Tomcat to finalize the update? Any advice much appreciated (the more specific the better).

A minor update, i.e. from 8.5.9 to 8.5.15 should be as simple as:

1) Shut down Tomcat
2) Make a backup of {tomcat}/lib directory (cause you never know, right?)
3) Copy the lib directory from 8.5.15 to the {tomcat}/lib overwriting
the old jar files
4) Start up Tomcat

Igal Sapir

Lucee Core Developer
Lucee.org <http://lucee.org/>

Kreuser, Peter

2017-05-16 15:27:06 UTC

Permalink

Igal,

-----Ursprüngliche Nachricht-----

Gesendet: Dienstag, 16. Mai 2017 16:44
Betreff: Re: how to upgrade tomcat 8.5.x?

1) Shut down Tomcat
2) Make a backup of {tomcat}/lib directory (cause you never know, right?)
3) Copy the lib directory from 8.5.15 to the {tomcat}/lib overwriting
the old jar files
4) Start up Tomcat
Igal Sapir
Lucee Core Developer
Lucee.org <http://lucee.org/>

I would disagree to do it this way.

I'd say a more robust (and the documented way) is to use a Tomcat-Home directory and a Tomcat-Base Directory.

$CATALINA_HOME holds the actual distributed Tomcat-"Binaries" (ZIP/TGZ),
$CATALINA_BASE holds your adapted config, libs and webapps.

This way you can just exchange the CATALINA_HOME with a new version (say 8.5.15) and restart Tomcat. In case there are differences in configs between versions, adapt your conf using https://tomcat.apache.org/migration-85.html#Tomcat_8.5.x_configuration_file_differences

https://tomcat.apache.org/tomcat-8.5-doc/introduction.html#Directories_and_Files
https://tomcat.apache.org/tomcat-8.5-doc/RUNNING.txt

Just my 2cts

Peter

Т��ХF�V�7V'67&�&R�R��âW6W'2�V�7V'67&�&TF��6B�6�R��&pФf�"FF�F��6��G2�R�

Igal @ Lucee.org

2017-05-16 16:18:02 UTC

Permalink

Post by Kreuser, Peter
I'd say a more robust (and the documented way) is to use a Tomcat-Home directory and a Tomcat-Base Directory.
$CATALINA_HOME holds the actual distributed Tomcat-"Binaries" (ZIP/TGZ),
$CATALINA_BASE holds your adapted config, libs and webapps.
This way you can just exchange the CATALINA_HOME with a new version (say 8.5.15) and restart Tomcat. In case there are differences in configs between versions, adapt your conf using https://tomcat.apache.org/migration-85.html#Tomcat_8.5.x_configuration_file_differences

I agree that separating the CATALINA_HOME from CATALINA_BASE is a much
better setup, but if Tomcat was not set up like that already then for a
minor upgrade this complicates the process.

The simplest way to upgrade is the one I documented.

Regards,

Igal Sapir
Lucee Core Developer
Lucee.org <http://lucee.org/>

Mark Thomas

2017-05-17 07:41:03 UTC

Permalink

Post by Igal @ Lucee.org

Post by Kreuser, Peter
I'd say a more robust (and the documented way) is to use a Tomcat-Home
directory and a Tomcat-Base Directory.
$CATALINA_HOME holds the actual distributed Tomcat-"Binaries" (ZIP/TGZ),
$CATALINA_BASE holds your adapted config, libs and webapps.
This way you can just exchange the CATALINA_HOME with a new version
(say 8.5.15) and restart Tomcat. In case there are differences in
configs between versions, adapt your conf using
https://tomcat.apache.org/migration-85.html#Tomcat_8.5.x_configuration_file_differences

I agree that separating the CATALINA_HOME from CATALINA_BASE is a much
better setup, but if Tomcat was not set up like that already then for a
minor upgrade this complicates the process.
The simplest way to upgrade is the one I documented.

That simple approach is incomplete. It assumes that:
a) the JARs in $CATALINA_HOME/bin haven't changed
b) the names of the JARs in $CATALINA_HOME/lib haven't changed
c) no configuration changes are required.

a) sometimes happens

b) happens when the JDT compiler is updated

c) can be checked via the migration guides

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

Igal @ Lucee.org

2017-05-19 17:14:33 UTC

Permalink

Post by Mark Thomas
a) the JARs in $CATALINA_HOME/bin haven't changed
b) the names of the JARs in $CATALINA_HOME/lib haven't changed
c) no configuration changes are required.
a) sometimes happens
b) happens when the JDT compiler is updated
c) can be checked via the migration guides

Most projects nowadays follow the semantic versioning spec, which
specifies that patch update and minor update (see items 6 and 7 at
http://semver.org/#spec-item-6 ) should be backwards compatible.

I expected Tomcat to follow this specification, and if it doesn't then I
highly recommend that you will consider adopting it.

I believe that most users expect a minor upgrade to be backwards
compatible.

Igal

Richard Huntrods

2017-05-17 16:58:55 UTC

Permalink

Post by Mark Thomas

Post by Igal @ Lucee.org

Post by Kreuser, Peter
I'd say a more robust (and the documented way) is to use a
Tomcat-Home directory and a Tomcat-Base Directory.
$CATALINA_HOME holds the actual distributed Tomcat-"Binaries"
(ZIP/TGZ),
$CATALINA_BASE holds your adapted config, libs and webapps.
This way you can just exchange the CATALINA_HOME with a new version
(say 8.5.15) and restart Tomcat. In case there are differences in
configs between versions, adapt your conf using
https://tomcat.apache.org/migration-85.html#Tomcat_8.5.x_configuration_file_differences

I agree that separating the CATALINA_HOME from CATALINA_BASE is a
much better setup, but if Tomcat was not set up like that already
then for a minor upgrade this complicates the process.
The simplest way to upgrade is the one I documented.

Well, I just upgraded my servers from Tomcat 8..5.12 to 8.5.14. The
complex way is to create a new tomcat directory for the new version,
then rename webapps to webapps.orig and create a new webapps directory
to hold my war files. Then compare all the config files and make
appropriate changes to the stock config files, then test. This takes a
while.

So for the minor change from 12 to 14, I decided to try a new way. On my
windows devel box, I unzipped a new download of 12 and a new download of
14 into their own new directories, then compared all the files in both
(yay for the ancient program "windiff"). I then built a batch file to
copy only the changed files and tested this. Once satisfied, I built a
shell script to make the same changes on my devel unix server, and
tested this. Once I was sure it worked without any problems, I ported
the script (and virgin 8.5.14 directory) to my production servers. On
scheduled maintenance I shut down each tomcat 12, ran the script and
then restarted tomcat. All worked perfectly.

Here's the file changes from 8.5.12 to 8.5.14, no including the changes

Post by Mark Thomas
#!/bin/sh
#
# update files in tomcat 8.5.12 to 8.5.14
#
# when done, rename apache-tomcat-8.5.12 to apache-tomcat-8.5.14
# then fix the symbolic link and restart tomcat
#
cp ./apache-tomcat-8.5.14/RELEASE-NOTES ../apps/apache-tomcat-8.5.12
cp ./apache-tomcat-8.5.14/bin/bootstrap.jar
../apps/apache-tomcat-8.5.12/bin
cp ./apache-tomcat-8.5.14/bin/tomcat-juli.jar
../apps/apache-tomcat-8.5.12/bin
cp ./apache-tomcat-8.5.14/lib/annotations-api.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-ant.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-ha.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-storeconfig.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-tribes.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/el-api.jar ../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/jasper-el.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/jasper.jar ../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/jaspic-api.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/jsp-api.jar ../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/servlet-api.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-api.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-coyote.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-dbcp.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-es.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-fr.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-ja.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-jdbc.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-jni.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-util-scan.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-util.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-websocket.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/websocket-api.jar
../apps/apache-tomcat-8.5.12/lib

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Daniel Savard

2017-05-17 22:58:55 UTC

Permalink

Post by Richard Huntrods

Post by Mark Thomas

Post by Igal @ Lucee.org

Post by Kreuser, Peter
I'd say a more robust (and the documented way) is to use a Tomcat-Home
directory and a Tomcat-Base Directory.
$CATALINA_HOME holds the actual distributed Tomcat-"Binaries" (ZIP/TGZ),
$CATALINA_BASE holds your adapted config, libs and webapps.
This way you can just exchange the CATALINA_HOME with a new version
(say 8.5.15) and restart Tomcat. In case there are differences in configs
between versions, adapt your conf using https://tomcat.apache.org/migr
ation-85.html#Tomcat_8.5.x_configuration_file_differences

I agree that separating the CATALINA_HOME from CATALINA_BASE is a much
better setup, but if Tomcat was not set up like that already then for a
minor upgrade this complicates the process.
The simplest way to upgrade is the one I documented.

Well, I just upgraded my servers from Tomcat 8..5.12 to 8.5.14. The
complex way is to create a new tomcat directory for the new version, then
rename webapps to webapps.orig and create a new webapps directory to hold
my war files. Then compare all the config files and make appropriate
changes to the stock config files, then test. This takes a while.
So for the minor change from 12 to 14, I decided to try a new way. On my
windows devel box, I unzipped a new download of 12 and a new download of 14
into their own new directories, then compared all the files in both (yay
for the ancient program "windiff"). I then built a batch file to copy only
the changed files and tested this. Once satisfied, I built a shell script
to make the same changes on my devel unix server, and tested this. Once I
was sure it worked without any problems, I ported the script (and virgin
8.5.14 directory) to my production servers. On scheduled maintenance I shut
down each tomcat 12, ran the script and then restarted tomcat. All worked
perfectly.
Here's the file changes from 8.5.12 to 8.5.14, no including the changes to
#!/bin/sh

Post by Mark Thomas
#
# update files in tomcat 8.5.12 to 8.5.14
#
# when done, rename apache-tomcat-8.5.12 to apache-tomcat-8.5.14
# then fix the symbolic link and restart tomcat
#
cp ./apache-tomcat-8.5.14/RELEASE-NOTES ../apps/apache-tomcat-8.5.12
cp ./apache-tomcat-8.5.14/bin/bootstrap.jar
../apps/apache-tomcat-8.5.12/bin
cp ./apache-tomcat-8.5.14/bin/tomcat-juli.jar
../apps/apache-tomcat-8.5.12/bin
cp ./apache-tomcat-8.5.14/lib/annotations-api.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-ant.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-ha.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-storeconfig.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina-tribes.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/catalina.jar ../apps/apache-tomcat-8.5.12/l
ib
cp ./apache-tomcat-8.5.14/lib/el-api.jar ../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/jasper-el.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/jasper.jar ../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/jaspic-api.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/jsp-api.jar ../apps/apache-tomcat-8.5.12/l
ib
cp ./apache-tomcat-8.5.14/lib/servlet-api.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-api.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-coyote.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-dbcp.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-es.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-fr.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-i18n-ja.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-jdbc.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-jni.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-util-scan.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-util.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/tomcat-websocket.jar
../apps/apache-tomcat-8.5.12/lib
cp ./apache-tomcat-8.5.14/lib/websocket-api.jar
../apps/apache-tomcat-8.5.12/lib

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Maybe a useless comment. However I upgraded from 8.0 to 8.5. I have both a
CATALINA_HOME and CATALINA_BASE and the upgrade was really easy and
summarizes almost entierly in changes for the new configuration syntax in
the server.xml file. Upgrading from a release to another is almost a no
brainer, as well as upgrading to a new Java version.

It may be a little more work to start with to setup two separated filetree,
but on the long run, it pays. I have to maintain and support about 70
instances of Tomcat and a dozen of applications as a sideline job.

-----------------
Daniel Savard

gkk gb

2017-05-19 15:28:04 UTC

Permalink

If my current Tomcat is installed in

/home/tomcat/dir1/apache-tomcat-8.5.9

and then I install the latest Tomcat in

/home/tomcat/dir1/apache-tomcat-8.5.15

how does Apache web server know to connect to the newer version of Tomcat? Is this established by the definition of CATALINA_HOME in .bash_profile? Or, some other way?

Can I install both Tomcat versions side by side and switch between them to verify everything works fine with the newer Tomcat before deleting the older Tomcat?

Post by Daniel Savard

Post by Richard Huntrods

Post by Mark Thomas

Post by Igal @ Lucee.org

Post by Kreuser, Peter
I'd say a more robust (and the documented way) is to use a Tomcat-Home
directory and a Tomcat-Base Directory.
$CATALINA_HOME holds the actual distributed Tomcat-"Binaries" (ZIP/TGZ),
$CATALINA_BASE holds your adapted config, libs and webapps.
This way you can just exchange the CATALINA_HOME with a new version
(say 8.5.15) and restart Tomcat. In case there are differences in configs
between versions, adapt your conf using https://tomcat.apache.org/migr
ation-85.html#Tomcat_8.5.x_configuration_file_differences

I agree that separating the CATALINA_HOME from CATALINA_BASE is a much
better setup, but if Tomcat was not set up like that already then for a
minor upgrade this complicates the process.
The simplest way to upgrade is the one I documented.

a) the JARs in $CATALINA_HOME/bin haven't changed
b) the names of the JARs in $CATALINA_HOME/lib haven't changed
c) no configuration changes are required.
a) sometimes happens
b) happens when the JDT compiler is updated
c) can be checked via the migration guides
Mark
Well, I just upgraded my servers from Tomcat 8..5.12 to 8.5.14. The
complex way is to create a new tomcat directory for the new version, then
rename webapps to webapps.orig and create a new webapps directory to hold
my war files. Then compare all the config files and make appropriate
changes to the stock config files, then test. This takes a while.

So for the minor change from 12 to 14, I decided to try a new way. On my
windows devel box, I unzipped a new download of 12 and a new download of 14
into their own new directories, then compared all the files in both (yay
for the ancient program "windiff"). I then built a batch file to copy only
the changed files and tested this. Once satisfied, I built a shell script
to make the same changes on my devel unix server, and tested this. Once I
was sure it worked without any problems, I ported the script (and virgin
8.5.14 directory) to my production servers. On scheduled maintenance I shut
down each tomcat 12, ran the script and then restarted tomcat. All worked
perfectly.
Here's the file changes from 8.5.12 to 8.5.14, no including the changes to
#!/bin/sh

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Maybe a useless comment. However I upgraded from 8.0 to 8.5. I have both a
CATALINA_HOME and CATALINA_BASE and the upgrade was really easy and
summarizes almost entierly in changes for the new configuration syntax in
the server.xml file. Upgrading from a release to another is almost a no
brainer, as well as upgrading to a new Java version.
It may be a little more work to start with to setup two separated filetree,
but on the long run, it pays. I have to maintain and support about 70
instances of Tomcat and a dozen of applications as a sideline job.
-----------------
Daniel Savard

Mark Eggers

2017-05-19 19:26:04 UTC

Permalink

GB,

Post by gkk gb
If my current Tomcat is installed in
/home/tomcat/dir1/apache-tomcat-8.5.9
and then I install the latest Tomcat in
/home/tomcat/dir1/apache-tomcat-8.5.15
how does Apache web server know to connect to the newer version of
Tomcat? Is this established by the definition of CATALINA_HOME in
.bash_profile? Or, some other way?

The connection is done (normally) via a port. It's either AJP and the
AJP port configured in server.xml, or HTTP (could be HTTPS) and the HTTP
(or HTTPS) port configured in server.xml

This depends on how your Apache HTTPD server is configured.

If you use the same ports, then only one Apache Tomcat can be running at
a time (can't have two processes listen on the same port - technically
address / port combination).

Post by gkk gb
Can I install both Tomcat versions side by side and switch between
them to verify everything works fine with the newer Tomcat before
deleting the older Tomcat?

Yep.

1. Install newer Tomcat
2. Make sure server.xml is set the way you need it to be
3. Copy web applications over to new Tomcat
4. Shut down old Tomcat
5. Start up new Tomcat
6. Test

Then make a decision. If the your applications have difficulties with
the new Tomcat, shut down the new Tomcat, start the old Tomcat, and
debug the issues on a development / test environment.

I do something similar to upgrade Tomcats, albeit with an Ant script,
separate CATALINA_HOME / CATALINA_BASE, and an appBase outside of
CATALINA_BASE.

This allows me to install new Tomcat versions without taking down the
old Tomcat. When it comes time to upgrade, I do the following:

1. Shut down the Tomcat service
2. Move two links to the new Tomcat version (CATALINA_HOME /
CATALINA_BASE)
3. Start up the Tomcat service

If there are issues, I can easily fall back to the old Tomcat with:

1. Shut down the Tomcat service
2. Move two links to the old Tomcat version
3. Start up the Tomcat service

All of the server.xml modification information is kept in a set of
property files which are versioned. The Ant scripts use the property
files to configure Tomcat instances.

Post by gkk gb

2017-05-17 12:58 GMT-04:00 Richard Huntrods

Post by Richard Huntrods

Post by Igal @ Lucee.org

Post by Kreuser, Peter
I'd say a more robust (and the documented way) is to use a
Tomcat-Home directory and a Tomcat-Base Directory.
$CATALINA_HOME holds the actual distributed
Tomcat-"Binaries" (ZIP/TGZ), $CATALINA_BASE holds your
adapted config, libs and webapps.
This way you can just exchange the CATALINA_HOME with a new
version (say 8.5.15) and restart Tomcat. In case there are
differences in configs between versions, adapt your conf
using https://tomcat.apache.org/migr
ation-85.html#Tomcat_8.5.x_configuration_file_differences

I agree that separating the CATALINA_HOME from CATALINA_BASE
is a much better setup, but if Tomcat was not set up like
that already then for a minor upgrade this complicates the
process.
The simplest way to upgrade is the one I documented.

That simple approach is incomplete. It assumes that: a) the
JARs in $CATALINA_HOME/bin haven't changed b) the names of the
JARs in $CATALINA_HOME/lib haven't changed c) no configuration
changes are required.
a) sometimes happens
b) happens when the JDT compiler is updated
c) can be checked via the migration guides
Mark
Well, I just upgraded my servers from Tomcat 8..5.12 to 8.5.14.
The complex way is to create a new tomcat directory for the new
version, then rename webapps to webapps.orig and create a new
webapps directory to hold my war files. Then compare all the
config files and make appropriate changes to the stock config
files, then test. This takes a while.

So for the minor change from 12 to 14, I decided to try a new
way. On my windows devel box, I unzipped a new download of 12 and
a new download of 14 into their own new directories, then
compared all the files in both (yay for the ancient program
"windiff"). I then built a batch file to copy only the changed
files and tested this. Once satisfied, I built a shell script to
make the same changes on my devel unix server, and tested this.
Once I was sure it worked without any problems, I ported the
script (and virgin 8.5.14 directory) to my production servers. On
scheduled maintenance I shut down each tomcat 12, ran the script
and then restarted tomcat. All worked perfectly.
Here's the file changes from 8.5.12 to 8.5.14, no including the
#!/bin/sh

#
# update files in tomcat 8.5.12 to 8.5.14 #
# when done, rename apache-tomcat-8.5.12 to
apache-tomcat-8.5.14
# then fix the symbolic link and restart tomcat #
cp ./apache-tomcat-8.5.14/RELEASE-NOTES
../apps/apache-tomcat-8.5.12 cp
./apache-tomcat-8.5.14/bin/bootstrap.jar
../apps/apache-tomcat-8.5.12/bin cp
./apache-tomcat-8.5.14/bin/tomcat-juli.jar
../apps/apache-tomcat-8.5.12/bin cp
./apache-tomcat-8.5.14/lib/annotations-api.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/catalina-ant.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/catalina-ha.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/catalina-storeconfig.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/catalina-tribes.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/catalina.jar
../apps/apache-tomcat-8.5.12/l ib cp
./apache-tomcat-8.5.14/lib/el-api.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/jasper-el.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/jasper.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/jaspic-api.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/jsp-api.jar
../apps/apache-tomcat-8.5.12/l ib cp
./apache-tomcat-8.5.14/lib/servlet-api.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/tomcat-api.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/tomcat-coyote.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/tomcat-dbcp.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/tomcat-i18n-es.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/tomcat-i18n-fr.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/tomcat-i18n-ja.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/tomcat-jdbc.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/tomcat-jni.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/tomcat-util-scan.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/tomcat-util.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/tomcat-websocket.jar
../apps/apache-tomcat-8.5.12/lib cp
./apache-tomcat-8.5.14/lib/websocket-api.jar
../apps/apache-tomcat-8.5.12/lib

--- This email has been checked for viruses by Avast antivirus
software. https://www.avast.com/antivirus

Maybe a useless comment. However I upgraded from 8.0 to 8.5. I have
both a CATALINA_HOME and CATALINA_BASE and the upgrade was really
easy and summarizes almost entierly in changes for the new
configuration syntax in the server.xml file. Upgrading from a
release to another is almost a no brainer, as well as upgrading to
a new Java version.
It may be a little more work to start with to setup two separated
filetree, but on the long run, it pays. I have to maintain and
support about 70 instances of Tomcat and a dozen of applications as
a sideline job.
----------------- Daniel Savard

. . . just my two cents
/mde/

Christopher Schultz

2017-05-20 23:37:16 UTC

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

Post by Mark Eggers
GB,

Post by gkk gb
If my current Tomcat is installed in
/home/tomcat/dir1/apache-tomcat-8.5.9
and then I install the latest Tomcat in
/home/tomcat/dir1/apache-tomcat-8.5.15
how does Apache web server know to connect to the newer version
of Tomcat? Is this established by the definition of CATALINA_HOME
in .bash_profile? Or, some other way?

The connection is done (normally) via a port. It's either AJP and
the AJP port configured in server.xml, or HTTP (could be HTTPS) and
the HTTP (or HTTPS) port configured in server.xml
This depends on how your Apache HTTPD server is configured.
If you use the same ports, then only one Apache Tomcat can be
running at a time (can't have two processes listen on the same port
- technically address / port combination).

Post by gkk gb
Can I install both Tomcat versions side by side and switch
between them to verify everything works fine with the newer
Tomcat before deleting the older Tomcat?

Yep.
1. Install newer Tomcat 2. Make sure server.xml is set the way you
need it to be 3. Copy web applications over to new Tomcat

I would always recommend using separate CATALINA_HOME and
CATALINA_BASE directories. You mention this below, but it's worth
reinforcing the fact that upgrades become even easier once this split
has been done.

Post by Mark Eggers
4. Shut down old Tomcat 5. Start up new Tomcat 6. Test
Then make a decision. If the your applications have difficulties
with the new Tomcat, shut down the new Tomcat, start the old
Tomcat, and debug the issues on a development / test environment.
I do something similar to upgrade Tomcats, albeit with an Ant
script, separate CATALINA_HOME / CATALINA_BASE, and an appBase
outside of CATALINA_BASE.
This allows me to install new Tomcat versions without taking down
1. Shut down the Tomcat service 2. Move two links to the new Tomcat
version (CATALINA_HOME / CATALINA_BASE) 3. Start up the Tomcat
service
If there are issues, I can easily fall back to the old Tomcat
1. Shut down the Tomcat service 2. Move two links to the old Tomcat
version 3. Start up the Tomcat service
All of the server.xml modification information is kept in a set of
property files which are versioned. The Ant scripts use the
property files to configure Tomcat instances.

This is roughly what we do as well: our ant-based build scripts build
server.xml (and context.xml for that matter) from a set of properties
that are specific to the application (and environment).

And of course Tomcat is started/stopped with those same scripts :)

Come to think of it... did I give you my Ant scripts ages ago? Or did
you develop your own? I think I may have promised to publish them, but
maybe never did.

- -chris

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkg0yoACgkQHPApP6U8
pFhWgw/9HiS07rClspn20IoXUDtgpaf4yIiz//wlNyO1UBFSALFnsJGsX47S8FYO
U370Lnq6calG9ufOIT/Jg6256O1YbGjJn62mFZmXJ5WeSIONxIOB/GBovVHa96+A
lRv4Skp5Pr8AVpPuCq00ADken1kMIu/u8Baqr57TujaBjapq7fyDoxdFJ9/OSEuC
jN4AGso6wrbr/je3EheOnBtIb2VDC0ruxHmqbLcWAYGMVroGmpGL1sMQoN1wV9xr
DesVIfNlubT997HEYC+oVNccw21svRJFTLJ2FTrSD9RrJDGYM/biholfvI3OAQIO
ApmrXD4jpqQvcTYhdVxEMspkN14e71lEnPzGfExxoZ906t5hb8kRoDnjOx/T3Rve
2bYrx/vlTWlv9LhZu0eLppG+X3xh+6ZHveIf2ekz+MWg36W5Sk6O8JLCoA5eoGV/
EotPgKEqM2Ldc+5T52bOf9wQPvd4MC1NNT25at+awBzIvjPoo1nBhITcGdQg1yNH
+wlJHCOVJzWjACchXDpKxzLzRzadatFcRsiVsM6pCMIXd8Cj4LT5sqxejmpQHorW
7hvl3/ZCNjrmdWYcJMz4QFRahVyD4YX9ezEjMalZjYrGhEAOiiRxccyfdo/NZizG
byEjQDJp0MIbfFVdWwqWRa7bN4Y8zCizhR2rYYVNJMi6FigCw7o=
=TqXZ
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

Igal @ Lucee.org

2017-05-21 21:36:00 UTC

Permalink

Chris,

Post by Christopher Schultz
This is roughly what we do as well: our ant-based build scripts build
server.xml (and context.xml for that matter) from a set of properties
that are specific to the application (and environment).
And of course Tomcat is started/stopped with those same scripts :)
Come to think of it... did I give you my Ant scripts ages ago? Or did
you develop your own? I think I may have promised to publish them, but
maybe never did.

Can you post those scripts somewhere? They can benefit many users.

Thanks,

Igal

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

Mark Eggers

2017-05-22 00:34:40 UTC

Permalink

Chris,

Post by Christopher Schultz
Mark,

Post by Mark Eggers
GB,

Post by gkk gb
If my current Tomcat is installed in
/home/tomcat/dir1/apache-tomcat-8.5.9
and then I install the latest Tomcat in
/home/tomcat/dir1/apache-tomcat-8.5.15
how does Apache web server know to connect to the newer version
of Tomcat? Is this established by the definition of CATALINA_HOME
in .bash_profile? Or, some other way?

The connection is done (normally) via a port. It's either AJP and
the AJP port configured in server.xml, or HTTP (could be HTTPS) and
the HTTP (or HTTPS) port configured in server.xml
This depends on how your Apache HTTPD server is configured.
If you use the same ports, then only one Apache Tomcat can be
running at a time (can't have two processes listen on the same port
- technically address / port combination).

Post by gkk gb
Can I install both Tomcat versions side by side and switch
between them to verify everything works fine with the newer
Tomcat before deleting the older Tomcat?

Yep.
1. Install newer Tomcat 2. Make sure server.xml is set the way you
need it to be 3. Copy web applications over to new Tomcat

I developed my own. I use the Ant scripts just for customizing Tomcat
installations.

I do have one slight issue with my current Ant scripts. The link task
isn't supposed to create a link if it already exists, but it does, and
actually creates a link inside of the existing link. This means that I
have a manual cleanup step to do, which is annoying.

Also, the Ant xml task doesn't handle namespaces well. I'll have to
figure out how to mangle tomcat-users.xml in a better fashion for the
8.x series.

I use a custom-built init script for starting, stopping, querying, and
getting the version of a Tomcat services. I'll have to build something
soon to handle systemd.

I use Maven, the Tomcat Maven plugin, and Jenkins to customize a WAR
file for a particular environment. Coupled with parallel deployments,
this basically allows us to update with no downtime.

Mark
/mde/

Christopher Schultz

2017-05-23 17:55:12 UTC

Permalink

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Mark,

I developed my own [build and deployment scripts]. I use the Ant
scripts just for customizing Tomcat installations.> I do have one
slight issue with my current Ant scripts. The link task isn't
supposed to create a link if it already exists, but it does, and
actually creates a link inside of the existing link. This means
that I have a manual cleanup step to do, which is annoying.
Also, the Ant xml task doesn't handle namespaces well. I'll have
to figure out how to mangle tomcat-users.xml in a better fashion
for the 8.x series.

Which XML task? We use XSLT to for example customize the manager.xml
deployment file that comes with a stock Tomcat to deploy a manager
with our protections enabled.

I use a custom-built init script for starting, stopping, querying,
and getting the version of a Tomcat services. I'll have to build
something soon to handle systemd.
I use Maven, the Tomcat Maven plugin, and Jenkins to customize a
WAR file for a particular environment. Coupled with parallel
deployments, this basically allows us to update with no downtime.

Nice!

I'd love to see a TomcatCon presentation from the community about
blue/green deployments with Tomcat. :)

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlkkd38ACgkQHPApP6U8
pFioNw/9FfT9G2reCKNLsArC07X8cW4gY6XOO2sZ4YNFJyhPq/sBrzPEpMaD9Zst
GBiygl9mMPKBb15LnD+fsW39mfmIWODdXUM5t/1wuRruMYLF1dzS0F/0Pok5Egy8
CNYP7TwRKZKAWmGePUG+58k6p2CgJgDKJjz4zfEjA4SBjCO3vLZ+In4HfDrkuk2R
0AYcnC5Y9DymLHIJHGYHJNWz2k5uRm3vkfBRaSLWZ3CAR7qGm4bTHKc3D7Cg30Th
e9bJ8EHdAmnNlAfDs4ovE+rt4b/QAk3zY46iEH/9HHhVmtDYK5DprSGdPm6k8kQl
e1W/CegzxcbCY8lBG64zIZcxkUPtnwxCyLydUdjl3P5PN2gcAwBMDglVVEC87dZB
GZJ/Uu8b6Oxj5T1DalU8PGDzBKziTLxlfYwIW/fFJZkEclGZk/mxY5nOIq1EHbKG
21aEmuvOOgQIaWiGy5PKOkXXstTWyxTUJehU6LVb1tlmIHIAZ5d3kFXWWqwTrnjn
jS9N9TSG42dwlKyrUygfy0hUYIlUYynAm+xbzybHhMCp9aPUvAbKZfa6PTlBQpDt
DC5YJQkqXiRb/iQWa0MstA5Iq5t+nT/SrW7f9fLeRFdB0zbOPSaS45v5V69rRTsV
O4M88UZ+UGWEzYAzdTzWV1FKRX6gv81ZHwMWXF5o+imML9jJy7E=
=pxvz
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

Mark Eggers

2017-05-25 17:04:35 UTC

Permalink

Chris,

Mark,

True blue-green deployments would take some additional work, but
that's not beyond the realm of possibility. I might spend some
time doing this with Elastic Beanstalk, since $work wishes to move
to AWS.

This was a presentation that I *really* wanted to get someone to do for
TomcatCon, but we couldn't find anyone to do it.
If you were able to research, prepare, and present this information at
an upcoming conference, I believe it would be well-attended.
I would certainly be there, taking notes.
-chris

Sorry about that. What I have right now is really not ready for prime time.

Most of the challenges that I've run into involve infrastructure and
process, not Tomcat per se. A lot of these issues can be solved with
suitable tools / infrastructure design. For example, Netflix seems to
have a nice freely available set of tools and processes.

Unfortunately I am under $constraints to keep the environment as generic
as possible.

Once I get most of the kinks worked out, I'll be happy to share that
with the community.

. . . just my (constrained) two cents
/mde/