tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Best practice application deployement
Date Tue, 07 Aug 2007 07:57:16 GMT
Hi Christopher,

> Ouch. Why do you delete the application before you stop 
> Tomcat? I would stop Tomcat and then delete the files.

We delete the war file before stopping tomcat to give Tomcat a chance to
auto-undeploy the application automatically.

I just read last night that auto-deploy/undeploy carries a performance
impact, is the performance impact really that significant just for
monitoring a directory?

> > rm -rf /usr/share/tomcat5/work/Catalina/localhost/application-1.1
> > rm -rf 
> /usr/share/tomcat5/conf/Catalina/localhost/application-1.1.xml
> > rm -rf /usr/share/tomcat5/webapps/application-1.1
> > cp /home/admin/application-1.1.war /usr/share/tomcat5/webapps
> > /etc/init.d/tomcat5 start
> How does this even work? The first line of the script deletes 
> /home/admin/application-1.1.war and the second-to-last line 
> tries to copy it back. Shouldn't the file not even exist?

The problem as I am made to understand from the developers is that the
context name is dependant on the application name and that specifically
specifying a context name does not do the trick. I have not tested this
myself yet, but plan to do so.
Even though the file name in the script are the same it is a different file
or different version at least of the same application.

> ant has an optional task to allow you to (re-)deploy WAR 
> files to a running Tomcat instance. This capability is 
> probably inherited by Maven, which is how you heard about it. 
> Maven is not required, though, so if you aren't using Maven, 
> you don't have to.
> Are your servers sharing any remote-mounted filesystems over 
> NFS or anything like that? I believe that Tomcat expands 
> deployed WAR files to its local work directory, so you could 
> potentially share WAR files over a network-mounted disk. 
> Then, simply replace the WAR file on the network and all 60 
> of your Tomcat instances will auto-re-deploy if configured to 
> do so. (I wouldn't recommend this for production, but that's 
> just my own personal bias).

An interesting idea... How would you make your tomcat unavailable during the
re-deployement of a new application?


This email has been scanned by the MessageLabs Email Security System.
For more information please visit 
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message