Re: retain context.xml across war updates
On Feb 6, 2014, at 1:02 PM, Mark Thomas ma...@apache.org wrote: On 06/02/2014 17:55, Steve Lopez wrote: Is there a way to ensure an applications context.xml isn't deleted across reloads of the war file?We have server-specific settings in each context.xml and are looking for a way to deploy the same WAR file across each Tomcat instance. My first attempt at this was to put the context.xml into ~ catalina /conf/Catalina/localhost/ROOT.xml. However, Tomcat deletes the file when the app is unloaded. Is there a setting to tell Tomcat *not* to delete the context.xml in ~catalina/conf/Catalina/[host]/[app]? If not, what is the 'best practice' for providing configuration settings to each Tomcat while also enabling a simple continuous integration and deployment of WAR files for an application across multiple Tc instances. Creating custom war files (one for each server) seems brittle and risky if the wrong war is accidentally deployed on the wrong server. Specifically, context.xml contains custom settings for memcached-session-manager which specifies the primary and fallback memcache host. These would be different for each server when using sticky sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/automatic-deployment.html HTH, Mark I can't find any way to navigate to that URL from within the Tomcat documentation. Maybe a link needs to be added somewhere on this page? http://tomcat.apache.org/tomcat-7.0-doc/deployer-howto.html --Jesse Barnum, President, 360Works http://www.360works.com Product updates and news on http://facebook.com/360Works (770) 234-9293 == Don't lose your data! http://360works.com/safetynet/ for FileMaker Server == - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: retain context.xml across war updates
From: Jesse Barnum [mailto:jsb_tom...@360works.com] Subject: Re: retain context.xml across war updates http://tomcat.apache.org/tomcat-7.0-doc/config/automatic-deployment.html I can't find any way to navigate to that URL from within the Tomcat documentation. It's reached from the last sentence of this section: http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Automatic_Application_Deployment That page is reachable from a couple of places in the configuration doc. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: retain context.xml across war updates
On Mar 2, 2014, at 9:58 AM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: It's reached from the last sentence of this section: http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Automatic_Application_Deployment That page is reachable from a couple of places in the configuration doc. - Chuck Thanks, I missed that. --Jesse Barnum, President, 360Works http://www.360works.com Product updates and news on http://facebook.com/360Works (770) 234-9293 == Don't lose your data! http://360works.com/safetynet/ for FileMaker Server ==
Re: retain context.xml across war updates
On 06/02/2014 17:55, Steve Lopez wrote: Is there a way to ensure an applications context.xml isn't deleted across reloads of the war file?We have server-specific settings in each context.xml and are looking for a way to deploy the same WAR file across each Tomcat instance. My first attempt at this was to put the context.xml into ~ catalina /conf/Catalina/localhost/ROOT.xml. However, Tomcat deletes the file when the app is unloaded. Is there a setting to tell Tomcat *not* to delete the context.xml in ~catalina/conf/Catalina/[host]/[app]? If not, what is the 'best practice' for providing configuration settings to each Tomcat while also enabling a simple continuous integration and deployment of WAR files for an application across multiple Tc instances. Creating custom war files (one for each server) seems brittle and risky if the wrong war is accidentally deployed on the wrong server. Specifically, context.xml contains custom settings for memcached-session-manager which specifies the primary and fallback memcache host. These would be different for each server when using sticky sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/automatic-deployment.html HTH, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: retain context.xml across war updates
Mark, which version of Tomcat 7 implemented the behavior described in that document? --Jesse Barnum, President, 360Works http://www.360works.com Product updates and news on http://facebook.com/360Works (770) 234-9293 == Don't lose your data! http://360works.com/safetynet/ for FileMaker Server == On Feb 6, 2014, at 1:02 PM, Mark Thomas ma...@apache.org wrote: On 06/02/2014 17:55, Steve Lopez wrote: Is there a way to ensure an applications context.xml isn't deleted across reloads of the war file?We have server-specific settings in each context.xml and are looking for a way to deploy the same WAR file across each Tomcat instance. My first attempt at this was to put the context.xml into ~ catalina /conf/Catalina/localhost/ROOT.xml. However, Tomcat deletes the file when the app is unloaded. Is there a setting to tell Tomcat *not* to delete the context.xml in ~catalina/conf/Catalina/[host]/[app]? If not, what is the 'best practice' for providing configuration settings to each Tomcat while also enabling a simple continuous integration and deployment of WAR files for an application across multiple Tc instances. Creating custom war files (one for each server) seems brittle and risky if the wrong war is accidentally deployed on the wrong server. Specifically, context.xml contains custom settings for memcached-session-manager which specifies the primary and fallback memcache host. These would be different for each server when using sticky sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/automatic-deployment.html HTH, Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: retain context.xml across war updates
Sorry - I forgot to include the version I'm using. It is 7.0.34 Soon to be 7.0.50 (on Ubuntu 12.0.4 LTS, 64-bit) -Original Message- From: Jesse Barnum [mailto:jsb_tom...@360works.com] Sent: Thursday, February 06, 2014 1:22 PM To: Tomcat Users List Subject: Re: retain context.xml across war updates Mark, which version of Tomcat 7 implemented the behavior described in that document? --Jesse Barnum, President, 360Works http://www.360works.com Product updates and news on http://facebook.com/360Works (770) 234-9293 == Don't lose your data! http://360works.com/safetynet/ for FileMaker Server == On Feb 6, 2014, at 1:02 PM, Mark Thomas ma...@apache.org wrote: On 06/02/2014 17:55, Steve Lopez wrote: Is there a way to ensure an applications context.xml isn't deleted across reloads of the war file?We have server-specific settings in each context.xml and are looking for a way to deploy the same WAR file across each Tomcat instance. My first attempt at this was to put the context.xml into ~ catalina /conf/Catalina/localhost/ROOT.xml. However, Tomcat deletes the file when the app is unloaded. Is there a setting to tell Tomcat *not* to delete the context.xml in ~catalina/conf/Catalina/[host]/[app]? If not, what is the 'best practice' for providing configuration settings to each Tomcat while also enabling a simple continuous integration and deployment of WAR files for an application across multiple Tc instances. Creating custom war files (one for each server) seems brittle and risky if the wrong war is accidentally deployed on the wrong server. Specifically, context.xml contains custom settings for memcached-session-manager which specifies the primary and fallback memcache host. These would be different for each server when using sticky sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/automatic-deployment.html HTH, 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: retain context.xml across war updates
On 06/02/2014 18:22, Jesse Barnum wrote: Mark, which version of Tomcat 7 implemented the behavior described in that document? Strictly, 7.0.48 but that wasn't released. 7.0.50 is the first release with that behaviour. The 8.0.x releases behave that way as well (some of the early RCs may not). Mark --Jesse Barnum, President, 360Works http://www.360works.com Product updates and news on http://facebook.com/360Works (770) 234-9293 == Don't lose your data! http://360works.com/safetynet/ for FileMaker Server == On Feb 6, 2014, at 1:02 PM, Mark Thomas ma...@apache.org wrote: On 06/02/2014 17:55, Steve Lopez wrote: Is there a way to ensure an applications context.xml isn't deleted across reloads of the war file?We have server-specific settings in each context.xml and are looking for a way to deploy the same WAR file across each Tomcat instance. My first attempt at this was to put the context.xml into ~ catalina /conf/Catalina/localhost/ROOT.xml. However, Tomcat deletes the file when the app is unloaded. Is there a setting to tell Tomcat *not* to delete the context.xml in ~catalina/conf/Catalina/[host]/[app]? If not, what is the 'best practice' for providing configuration settings to each Tomcat while also enabling a simple continuous integration and deployment of WAR files for an application across multiple Tc instances. Creating custom war files (one for each server) seems brittle and risky if the wrong war is accidentally deployed on the wrong server. Specifically, context.xml contains custom settings for memcached-session-manager which specifies the primary and fallback memcache host. These would be different for each server when using sticky sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/automatic-deployment.html HTH, 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: retain context.xml across war updates
Thanks, that explains why it's not working for me (I have 7.0.35). --Jesse Barnum, President, 360Works http://www.360works.com Product updates and news on http://facebook.com/360Works (770) 234-9293 == Don't lose your data! http://360works.com/safetynet/ for FileMaker Server == On Feb 6, 2014, at 1:54 PM, Mark Thomas ma...@apache.org wrote: On 06/02/2014 18:22, Jesse Barnum wrote: Mark, which version of Tomcat 7 implemented the behavior described in that document? Strictly, 7.0.48 but that wasn't released. 7.0.50 is the first release with that behaviour. The 8.0.x releases behave that way as well (some of the early RCs may not). Mark --Jesse Barnum, President, 360Works http://www.360works.com Product updates and news on http://facebook.com/360Works (770) 234-9293 == Don't lose your data! http://360works.com/safetynet/ for FileMaker Server == On Feb 6, 2014, at 1:02 PM, Mark Thomas ma...@apache.org wrote: On 06/02/2014 17:55, Steve Lopez wrote: Is there a way to ensure an applications context.xml isn't deleted across reloads of the war file?We have server-specific settings in each context.xml and are looking for a way to deploy the same WAR file across each Tomcat instance. My first attempt at this was to put the context.xml into ~ catalina /conf/Catalina/localhost/ROOT.xml. However, Tomcat deletes the file when the app is unloaded. Is there a setting to tell Tomcat *not* to delete the context.xml in ~catalina/conf/Catalina/[host]/[app]? If not, what is the 'best practice' for providing configuration settings to each Tomcat while also enabling a simple continuous integration and deployment of WAR files for an application across multiple Tc instances. Creating custom war files (one for each server) seems brittle and risky if the wrong war is accidentally deployed on the wrong server. Specifically, context.xml contains custom settings for memcached-session-manager which specifies the primary and fallback memcache host. These would be different for each server when using sticky sessions. http://tomcat.apache.org/tomcat-7.0-doc/config/automatic-deployment.html HTH, 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
