Tomcat custom location for configuration

Discussion:

Amit Pande

2018-10-02 16:41:39 UTC

Hello SMEs,

I am looking at Tomcat documentation to see if there is a way to move the â<Tomcat_Base_Folder>/confâ to a custom location and use this path while running the startup/shutdown scripts.

I have looked at the https://github.com/apache/tomcat85/blob/TOMCAT_8_5_34/java/org/apache/catalina/startup/Catalina.java and confirmed we can pass a -config <path_to_server_dot_xml> to the Tomcat scripts (catalina.bat/sh, startup.bat/sh, etc).

Wanted to confirm:

1. Why is â-configâ option not documented as part of help of the startup/shutdown scripts? Is this a supported configuration that we can use without worrying about future breaking changes in this?
2. Currently, as part of â-configâ option weâre able to pass on the path to server.xml only. What is required to be done so that entire Tomcat configuration (conf directory) can be moved to a custom location?
3. I am still debugging why, but on Linux setups, I have observed âconfigtestâ script isnât working with â-config <path_to_server_dot_xml>â. I am seeing âWARNING: Unable to load server configuration from [path_to_server_dot_xml] Configuration error detected!â. Is this know issue on Linux system? It seemed to work fine for Windows.

Appreciate your inputs.

Thanks,
Amit

Mark Thomas

2018-10-03 15:16:48 UTC

Permalink

Post by Amit Pande
Hello SMEs,
I am looking at Tomcat documentation to see if there is a way to move the “<Tomcat_Base_Folder>/conf” to a custom location and use this path while running the startup/shutdown scripts.

Why? What problem are you trying to solve?

Post by Amit Pande
I have looked at the https://github.com/apache/tomcat85/blob/TOMCAT_8_5_34/java/org/apache/catalina/startup/Catalina.java and confirmed we can pass a -config <path_to_server_dot_xml> to the Tomcat scripts (catalina.bat/sh, startup.bat/sh, etc).
1. Why is “-config” option not documented as part of help of the startup/shutdown scripts? Is this a supported configuration that we can use without worrying about future breaking changes in this?

It appears that this dates back to Tomcat 4.0.x (I couldn't find it in
3.3.x). It isn't something that I have seen used very much.

If I had to guess, I'd say the option was added either when server.xml
was the only configuration file or the location of the other
configuration files could be specified in server.xml.

Over the years additional configuration files were added to the default
location and, because the -config option was little used, the
requirement to make that location configurable wasn't considered.

Post by Amit Pande
2. Currently, as part of “-config” option we’re able to pass on the path to server.xml only. What is required to be done so that entire Tomcat configuration (conf directory) can be moved to a custom location?

Looks like a fair amount of work as $CATALINA_BASE/conf/ is hard-coded
in a *lot* of places. Making it configurable is going to be very
invasive. There would need to be a very strong justification for a
change along those lines.

Post by Amit Pande
3. I am still debugging why, but on Linux setups, I have observed “configtest” script isn’t working with “-config <path_to_server_dot_xml>”. I am seeing “WARNING: Unable to load server configuration from [path_to_server_dot_xml] Configuration error detected!”. Is this know issue on Linux system? It seemed to work fine for Windows.

I suspect it is a bug.

Post by Amit Pande
Appreciate your inputs.

Amit Pande

2018-10-03 16:18:28 UTC

Permalink

Thank you so much, Mark!

In our case, the server.xml contains some information which is generated run time (pre-config before Tomcat is started) like the paths to key store and trust store, cipher suites, etc.

Also, we have an active-passive cluster setup in which only the currently active node has the access to a shared disk which has all our product configuration data including the key store, trust store files needed in server.xml.

We have a requirement to share the configuration across both the nodes of the cluster to avoid keeping duplicate copies of configuration (server.xml). And since some of the server.xml configuration is generated runtime, it isn’t trivial in our case to keep these copies in sync.

This is the prime reason to have a shared Tomcat configuration. We may also want, in future, to spawn and additional instance of Tomcat with re-usable configuration (except adjusting the port numbers ).

The not-so-elegant choice we might have is to move the entire Tomcat installation to this cluster aware shared storage but defeats the purpose of having a shared disk for configuration data and not the binaries.

What alternates should we explore?

Thanks,
Amit

Why? What problem are you trying to solve?

I suspect it is a bug.

Post by Amit Pande
Appreciate your inputs.

At this point my recommendation would be to look at alternative
solutions rather than using -config. Once we know what the requirement
is, we can provide some advice.

Mark

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

B�KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKCB��[��X��ܚX�KK[XZ[�\�\��][��X��ܚX�P�X�]�\X�K�ܙ�B��܈Y][ۘ[��[X[��K[

Mark Thomas

2018-10-04 13:38:22 UTC

Permalink

Post by Amit Pande
Thank you so much, Mark!
In our case, the server.xml contains some information which is generated run time (pre-config before Tomcat is started) like the paths to key store and trust store, cipher suites, etc.
Also, we have an active-passive cluster setup in which only the currently active node has the access to a shared disk which has all our product configuration data including the key store, trust store files needed in server.xml.
We have a requirement to share the configuration across both the nodes of the cluster to avoid keeping duplicate copies of configuration (server.xml). And since some of the server.xml configuration is generated runtime, it isn’t trivial in our case to keep these copies in sync.
This is the prime reason to have a shared Tomcat configuration. We may also want, in future, to spawn and additional instance of Tomcat with re-usable configuration (except adjusting the port numbers ).
The not-so-elegant choice we might have is to move the entire Tomcat installation to this cluster aware shared storage but defeats the purpose of having a shared disk for configuration data and not the binaries.
What alternates should we explore?

You could look at using separate CATALINA_HOME and CATALINA_BASE. See
https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE

Whether have the web applications on the node or the shared storage is
arguable either way. If you want it on the node, just use an absolute
path that points to someone on the node for appBase.

Mark

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

Amit Pande

2018-10-04 16:17:22 UTC

Permalink

Thanks! I will take a detailed relook at using CATALINA_BASE and keep you posted.

Also, since the "-config" option is there since 4.0.x time till now, would it be safe to assume that this option won't be deprecated since some users (admittedly not too many) might actually be using it?
If it's going to stay, do you feel it's worth documenting (till the time it isn't actually deprecated with some alternate)?

I agree while not desirable at the moment, using "-config" solves our problem. So, we might have to use this as last fallback option.

Thanks,
Amit

Christopher Schultz

2018-10-04 17:15:41 UTC

Permalink

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

Amit,

Post by Amit Pande
Thanks! I will take a detailed relook at using CATALINA_BASE and keep you posted.
Also, since the "-config" option is there since 4.0.x time till
now, would it be safe to assume that this option won't be
deprecated since some users (admittedly not too many) might
actually be using it? If it's going to stay, do you feel it's worth
documenting (till the time it isn't actually deprecated with some
alternate)?
I agree while not desirable at the moment, using "-config" solves
our problem. So, we might have to use this as last fallback
option.

It sounds like this feature barely works and probably doesn't work in
many situations.

My vote would be to deprecate it immediately and remove it completely
in Tomcat 10.

I'm sorry, but I don't think I understand why you cannot use
CATALINA_BASE as "usual" in your situation.

- -chris

Post by Amit Pande

Post by Amit Pande
Thank you so much, Mark!
In our case, the server.xml contains some information which is
generated run time (pre-config before Tomcat is started) like the
paths to key store and trust store, cipher suites, etc.
Also, we have an active-passive cluster setup in which only the
currently active node has the access to a shared disk which has
all our product configuration data including the key store,
trust store files needed in server.xml.
We have a requirement to share the configuration across both the
nodes of the cluster to avoid keeping duplicate copies of
configuration (server.xml). And since some of the server.xml
configuration is generated runtime, it isn’t trivial in our case
to keep these copies in sync.
This is the prime reason to have a shared Tomcat configuration.
We may also want, in future, to spawn and additional instance of
Tomcat with re-usable configuration (except adjusting the port
numbers ).
The not-so-elegant choice we might have is to move the entire
Tomcat installation to this cluster aware shared storage but
defeats the purpose of having a shared disk for configuration
data and not the binaries.
What alternates should we explore?

You could look at using separate CATALINA_HOME and CATALINA_BASE. See
https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HO

ME_and_CATALINA_BASE

Post by Amit Pande
Whether have the web applications on the node or the shared
storage is arguable either way. If you want it on the node, just
use an absolute path that points to someone on the node for
appBase.
Mark
---------------------------------------------------------------------
---------------------------------------------------------------------

-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlu2SrwACgkQHPApP6U8
pFjlHw/+OZ8FgsTCHvzIIAYBRdAQ+If0M3Q7Wpp7w/tqUYjbHgERPBiof2arPft5
ir2tfUh11M0YiUvTPXfzzq7BHe5sXsDQHTxLimN1gq6+WOlZVd3k//giFQUmcwsK
RZtKUQUnGWUsjJ/n7z4rWna+gdleukWQ0k7qgbRR/dAiaAUd2mRfy4LgKpHvTVex
y6SXSmcGZ963vzPuZurMIyfPY2iUxb7Y1dbC8Pv7J0vAWhw1we08t33oMJa3Pcp4
vgV2Ylc6nwyw4LpFcTdNOzWaLIKBwJ4zwv2rQW9Tp8zhiU6O5BfVmzP3Zo04K18x
z1Zvw9mhOISIWn0vE+k6WxU/t17UVKYonPUBwJ0JelVNBE/tGsCSwiHK67gBhs0F
K/+QN8+625TDcUmxYtTMdXQVel/ZvWCrdVZKCJlM3uHSsSySoPhkQU+gCt9PExx9
YIgxzzViI3NiIkeobf8VmBMtZKaYWLWa6+eSoVVmj8UA7Glj5/tvT8o1AXDerYEk
kNWojPCOMx1l6rgysrlX6pRY3ltDnqGmlkzhxrU72afUXMpZ9VhKVawZ5457SEan
mYWGR5o09lmUE4VBFt87yL+VVSdmlckrC/2hQjDbK6qHQMUDIM6fs98mJ/fgVE2m
pL9gZG/4J3Tp6nQEFuAKehtFO+aQmRk6UKP6iW+ux2iarzQ5Z7k=
=32WJ
-----END PGP SIGNATURE-----

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

Amit Pande

2018-10-26 16:44:51 UTC

Permalink

Thank you once again, Chris and Mark!

https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE

Was able to meet our requirement of moving Tomcat configuration to a custom location using a different CATALINA_BASE.

The "-config" option will be cleaned up in next Tomcat release(s), right?

Thanks,
Amit

On 10/4/18, 12:15 PM, "Christopher Schultz" <***@christopherschultz.net> wrote:

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

Amit,

Post by Amit Pande

Post by Amit Pande
Thank you so much, Mark!
In our case, the server.xml contains some information which is
generated run time (pre-config before Tomcat is started) like the
paths to key store and trust store, cipher suites, etc.
Also, we have an active-passive cluster setup in which only the
currently active node has the access to a shared disk which has
all our product configuration data including the key store,
trust store files needed in server.xml.
We have a requirement to share the configuration across both the
nodes of the cluster to avoid keeping duplicate copies of
configuration (server.xml). And since some of the server.xml
configuration is generated runtime, it isn’t trivial in our case
to keep these copies in sync.
This is the prime reason to have a shared Tomcat configuration.
We may also want, in future, to spawn and additional instance of
Tomcat with re-usable configuration (except adjusting the port
numbers ).
The not-so-elegant choice we might have is to move the entire
Tomcat installation to this cluster aware shared storage but
defeats the purpose of having a shared disk for configuration
data and not the binaries.
What alternates should we explore?

You could look at using separate CATALINA_HOME and CATALINA_BASE. See
Whether have the web applications on the node or the shared
storage is arguable either way. If you want it on the node, just
use an absolute path that points to someone on the node for
appBase.
Mark
---------------------------------------------------------------------
---------------------------------------------------------------------

Igal Sapir

2018-10-27 05:07:16 UTC

Permalink

Amit,

Post by Amit Pande
Thank you once again, Chris and Mark!
https://tomcat.apache.org/tomcat-9.0-doc/introduction.html#CATALINA_HOME_and_CATALINA_BASE
Was able to meet our requirement of moving Tomcat configuration to a
custom location using a different CATALINA_BASE.

Great!

Post by Amit Pande
The "-config" option will be cleaned up in next Tomcat release(s), right?

It will probably be removed in a future version, yes. That's what Chris
meant in writing:

My vote would be to deprecate it immediately and remove it completely

Post by Amit Pande

Post by Christopher Schultz
in Tomcat 10.

Best,

Igal

Thanks,

Post by Amit Pande
Amit
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Amit,

Post by Christopher Schultz
Thanks! I will take a detailed relook at using CATALINA_BASE and
keep you posted.
Also, since the "-config" option is there since 4.0.x time till
now, would it be safe to assume that this option won't be
deprecated since some users (admittedly not too many) might
actually be using it? If it's going to stay, do you feel it's worth
documenting (till the time it isn't actually deprecated with some
alternate)?
I agree while not desirable at the moment, using "-config" solves
our problem. So, we might have to use this as last fallback
option.

It sounds like this feature barely works and probably doesn't work in
many situations.
My vote would be to deprecate it immediately and remove it completely
in Tomcat 10.
I'm sorry, but I don't think I understand why you cannot use
CATALINA_BASE as "usual" in your situation.
- -chris

Post by Christopher Schultz

Post by Amit Pande
Thank you so much, Mark!
In our case, the server.xml contains some information which is
generated run time (pre-config before Tomcat is started) like the
paths to key store and trust store, cipher suites, etc.
Also, we have an active-passive cluster setup in which only the
currently active node has the access to a shared disk which has
all our product configuration data including the key store,
trust store files needed in server.xml.
We have a requirement to share the configuration across both the
nodes of the cluster to avoid keeping duplicate copies of
configuration (server.xml). And since some of the server.xml
configuration is generated runtime, it isnât trivial in our case
to keep these copies in sync.
This is the prime reason to have a shared Tomcat configuration.
We may also want, in future, to spawn and additional instance of
Tomcat with re-usable configuration (except adjusting the port
numbers ).
The not-so-elegant choice we might have is to move the entire
Tomcat installation to this cluster aware shared storage but
defeats the purpose of having a shared disk for configuration
data and not the binaries.
What alternates should we explore?