Re: [EXTERNAL] Re: Tomcat custom location for configuration
Amit, On Fri, Oct 26, 2018 at 9:45 AM Amit Pande wrote: > 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! > 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 >> in Tomcat 10. >> > Best, Igal Thanks, > Amit > > On 10/4/18, 12:15 PM, "Christopher Schultz" > wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Amit, > > On 10/4/18 12:17, Amit Pande wrote: > > 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 > > > On 10/4/18, 8:38 AM, "Mark Thomas" wrote: > > > > On 03/10/18 17:18, Amit Pande wrote: > >> 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 > > > > - > > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > > > > > - > > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > -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 > kNWojPCOMx1l6rgysrlX6pRY3ltDnqGmlkzhxrU72afUXMpZ9VhKV
Re: [EXTERNAL] Re: Tomcat custom location for configuration
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" wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Amit, On 10/4/18 12:17, Amit Pande wrote: > 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 > On 10/4/18, 8:38 AM, "Mark Thomas" wrote: > > On 03/10/18 17:18, Amit Pande wrote: >> 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 > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -
Re: [EXTERNAL] Re: Tomcat custom location for configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Amit, On 10/4/18 12:17, Amit Pande wrote: > 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 > On 10/4/18, 8:38 AM, "Mark Thomas" wrote: > > On 03/10/18 17:18, Amit Pande wrote: >> 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 > > 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXTERNAL] Re: Tomcat custom location for configuration
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 On 10/4/18, 8:38 AM, "Mark Thomas" wrote: On 03/10/18 17:18, Amit Pande wrote: > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXTERNAL] Re: Tomcat custom location for configuration
On 03/10/18 17:18, Amit Pande wrote: > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [EXTERNAL] Re: Tomcat custom location for configuration
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 On 10/3/18, 10:16 AM, "Mark Thomas" wrote: On 02/10/18 17:41, Amit Pande wrote: > Hello SMEs, > > I am looking at Tomcat documentation to see if there is a way to move the “/conf” to a custom location and use this path while running the startup/shutdown scripts. Why? What problem are you trying to solve? > 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 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? 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. > 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. > 3. I am still debugging why, but on Linux setups, I have observed “configtest” script isn’t working with “-config ”. 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. > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
