Tomcat custom location for configuration

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Tomcat custom location for configuration

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.

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
Reply | Threaded
Open this post in threaded view
|

Re: Tomcat custom location for configuration

markt
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 “<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?

> 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?

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 <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.

> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: Tomcat custom location for configuration

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?

Thanks,
Amit

On 10/3/18, 10:16 AM, "Mark Thomas" <[hidden email]> 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 “<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?
   
    > 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?
   
    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 <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.
   
    > 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: [hidden email]
    For additional commands, e-mail: [hidden email]
   
   


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: Tomcat custom location for configuration

markt
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: Tomcat custom location for configuration

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.

Thanks,
Amit


On 10/4/18, 8:38 AM, "Mark Thomas" <[hidden email]> 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: [hidden email]
    For additional commands, e-mail: [hidden email]
   
   


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: Tomcat custom location for configuration

Christopher Schultz-2
-----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" <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
-----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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: Tomcat custom location for configuration

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.

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

Thanks,
Amit

On 10/4/18, 12:15 PM, "Christopher Schultz" <[hidden email]> 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" <[hidden email]> 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: [hidden email]
    > For additional commands, e-mail: [hidden email]
    >
    >
    >
    >
    > ---------------------------------------------------------------------
    >
    >
    To unsubscribe, e-mail: [hidden email]
    > For additional commands, e-mail: [hidden email]
    >
    -----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: [hidden email]
    For additional commands, e-mail: [hidden email]
   
   


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [EXTERNAL] Re: Tomcat custom location for configuration

Igal Sapir
Amit,

On Fri, Oct 26, 2018 at 9:45 AM Amit Pande <[hidden email]> 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" <[hidden email]>
> 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" <[hidden email]> 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: [hidden email]
>     > For additional commands, e-mail: [hidden email]
>     >
>     >
>     >
>     >
>     > ---------------------------------------------------------------------
>     >
>     >
>     To unsubscribe, e-mail: [hidden email]
>     > For additional commands, e-mail: [hidden email]
>     >
>     -----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: [hidden email]
>     For additional commands, e-mail: [hidden email]
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>