Aditya,
On 10/19/23 14:42, Aditya Shastri wrote:
The way I do the start.sh in my Catalina base is:
BASEDIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )/..
export CATALINA_BASE=$(realpath ${BASEDIR})
/opt/tomcat/tomcat-9/tomcat-9-latest/bin/startup.sh
I could just say $(realpath /opt/tomcat/tomcat-9/tomcat-9-latest)
The old version is we get rid off after 7 days just in case a rollback is
needed.
Depending upon the system, `realpath` may or may not resolve all
symlinks. On Linux, the man page indicates that the -P switch can be
used to resolve them, but that appears to be a GNU-only option.
`realpath` on my Linux system seems to replace symlinks with their
physical resolution.
You didn't give an example, but yes, you could say
CATALINA_BASE=$( realpath ${whatever} )
And probably get the behavior I'm describing.
It may be appropriate for Tomcat to try to do that kind of thing for
you, but maybe this would be better to simply "recommend" in cases like
yours. It's very easy to do this properly for a single environment by
just sticking something into bin/setenv.sh to resolve the path to a
physical one. It may be more difficult for Tomcat to solve that for all
potential environments where it may run.
> As for Windows, I was under the impression that they are not big fans
of symlinks anyway so maybe that's ok? :-D
You might be surprised. There are soft-ish-links and hard-ish-links in
NTFS plus some other hand-wavy things in DOS/Windows land. I don't
pretend to understand them all, but I've been surprised to discover that
various weird combinations of special symbols can be used along with
environment variables to get paths in certain forms under Windows.
-chris
-Original Message-
From: Christopher Schultz
Sent: Wednesday, October 18, 2023 7:32 PM
To: users@tomcat.apache.org
Subject: Re: Tomcat minor update
Mark and Aditya,
On 10/18/23 04:21, Mark Thomas wrote:
On 17/10/2023 22:47, Aditya Shastri wrote:
Hello,
We have several tomcat instances that use a single CATALINA_HOME which
is a symlink for a specific version. The Tomcat instance we use is
very barebones and doesn't have any of the apps that come with it.
For example,
The CATALINA_HOME points to a symlink
/opt/tomcat/tomcat-9/tomcat-9-latest ->
/opt/tomcat/tomcat-9/apache-tomcat-9.0.80.
Now, if I want to upgrade to apache-tomcat-9.0.82, I normally do the
following steps:
1. Stop all the running instances of tomcat in the various
'CATALINA_BASE'.
2. Update the symlink /opt/tomcat/tomcat-9/tomcat-9-latest from
/opt/tomcat/tomcat-9/apache-tomcat-9.0.80 to
/opt/tomcat/tomcat-9/apache-tomcat-9.0.82.
3. Start all the instances.
This method appears to work, and I read it as the most appropriate
method.
My question is, can I change the symlink,
'/opt/tomcat/tomcat-9/tomcat-9-latest', while all the instances are
running and restart the instances when I have downtime?
Probably not. You might get away with it sometimes but sometimes you are
going to see errors.
Does Tomcat load all the CATALINA_HOME jar(s) (not including the
webapps folder) and config to memory thereby not caring if the
libraries have changed or does it realize that something has changed?
No. The JVM loads classes when they are first referenced.
The issue will be if you update the symlink, then Tomcat tries to load
another class and the class from the new version is not compatible with
the classes from the old version. A failure is unlikely but not
impossible. I wouldn't risk it.
I wonder if we could solve this, at least on *NIX, by resolving
CATALINA_HOME by using `readlink -f`. This would allow you to use a
symlink to point to Tomcat but after catalina.sh is invoked,
CATALINA_HOME could be replaced with a canonicalized one which does not
contain a symlink anymore. Maybe there is a similar
utility/command/path-mangling-magic available on Windows?
That would allow you to change the symlink and not disturb any
currently-running Tomcat instances. You would obviously not want to
remove the old version from the disk before shutting-down those
instances, of course.
-chris
The information in this electronic mail communication (e-mail) contains
confidential information which is the property of the sender and may be
protected by the attorney-client privilege and/or attorney work product
doctrine. It is intended solely for the addressee. Access to this e-mail by
anyone else is unauthorized by the sender. If you are not the intended
recipient, you are hereby notified that any disclosure, copying, or
distribution of the contents of this e-mail transmission or the taking or
omission of any action in reliance thereon or pursuant thereto, is prohibited,
and may be unlawful. If you received this e-mail in error, please notify us
immediately of your receipt of this message
