You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Aditya Shastri <ad...@gmail.com> on 2023/10/17 21:47:58 UTC
Tomcat minor update
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?
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?
Please let me know!
Thanks!
Configuration:
Tomcat version: 9.0.80
OS: Oracle Linux 7
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat minor update
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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 <ch...@christopherschultz.net>
> 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 by e-mail and destroy this communication, any attachments, and all copies thereof.
>
> Southwest Gas Corporation does not guarantee the privacy or security of information transmitted by facsimile (fax) or other unsecure electronic means (including email). By choosing to send or receive information, including confidential or personal identifying information, via fax or unencrypted e-mail, you consent to accept any associated risk.
>
> Thank you for your cooperation.
>
> ************************************************************************
> ************************************************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat minor update
Posted by Aditya Shastri <Ad...@swgas.com>.
That's interesting.
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.
As for Windows, I was under the impression that they are not big fans of symlinks anyway so maybe that's ok? :-D
Thank you Mark and Chris!
-----Original Message-----
From: Christopher Schultz <ch...@christopherschultz.net>
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 by e-mail and destroy this communication, any attachments, and all copies thereof.
Southwest Gas Corporation does not guarantee the privacy or security of information transmitted by facsimile (fax) or other unsecure electronic means (including email). By choosing to send or receive information, including confidential or personal identifying information, via fax or unencrypted e-mail, you consent to accept any associated risk.
Thank you for your cooperation.
************************************************************************
************************************************************************
Re: Tomcat minor update
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat minor update
Posted by Mark Thomas <ma...@apache.org>.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org