Deploying to Tomcat using Ant
If you're using Tomcat 4.1.x, did you know you can deploy using an Ant task that ships with Tomcat. You'll need to add $CATALINA_HOME/server/lib/catalina-ant.jar to your classpath, but then you can configure your ant task as follows:
<taskdef name="deploy" classname="org.apache.catalina.ant.DeployTask"/> <deploy url="${manager.url}" username="${manager.username}" password="${manager.password}" path="/${name}" war="file:/${dist.dir}/${name}.war" />
I haven't tried it, but it looks cool. Right now I use a simple copy task that works pretty well for me, so no need to change at this point.
<target name="deploy" depends="package-web" if="tomcat.home" description="unwar into the servlet container's deployment directory"> <unwar src="${webapp.dist}/${webapp.war}" dest="${tomcat.home}/webapps/${webapp.name}"/> </target>
If you know of any advantages to using Tomcat's deploy task, or you'd like to share your experience using it - please post a comment.
Posted by Anthony Eden on February 07, 2003 at 02:47 PM MST #
Posted by Jano on February 07, 2003 at 04:16 PM MST #
Posted by Matt on February 07, 2003 at 04:27 PM MST #
Posted by Kurt on February 07, 2003 at 05:32 PM MST #
Posted by John Munsch on February 07, 2003 at 08:53 PM MST #
Posted by David Perkowski on February 08, 2003 at 01:25 AM MST #
This is appropriate when you want to deploy the entire war file. I love using it for production deployments.
Windows users should note that you are going to have problems with the tomcat deployer unless you set the context options antiResourceLocking and antiJarLocking to true in $CATALINA_HOME/conf/context.xml.
(See: tomcat FAQ on locking issues)
This is not recommended for production since it is a performance pig, but if you do not do the above, the jars from the previous app reload will not unload and you will have problems. I think the last comment on this thread alludes to the problem.
The workaround is to restart tomcat each time you deploy and this is definitely not optimal.
Even with the copy file approach on windows, you probably want to make sure the tomcat options are set to true.
The way that tomcat avoids windows locking issues is to copy the exploded war contents into tmp/context-[0-n] and redirect inbound requests to that versioned directory.
After a while, you'll want to clean out that tmp directory because tomcat does not clean up after itself. It just keeps creating new directories after the app is reloaded.
This is not an issue under linux and it isn't recommended to use those options at all since linux doesn't have the same issues with locking resources and files.
Posted by Rick Fisk on March 09, 2007 at 05:26 PM MST #
This is appropriate when you want to deploy the entire war file. I love using it for production deployments.
Windows users should note that you are going to have problems with the tomcat deployer unless you set the context options antiResourceLocking and antiJarLocking to true in $CATALINA_HOME/conf/context.xml.
(See: tomcat FAQ on locking issues)
This is not recommended for production since it is a performance pig, but if you do not do the above, the jars from the previous app reload will not unload and you will have problems. I think the last comment on this thread alludes to the problem.
The workaround is to restart tomcat each time you deploy and this is definitely not optimal.
Even with the copy file approach on windows, you probably want to make sure the tomcat options are set to true.
The way that tomcat avoids windows locking issues is to copy the exploded war contents into tmp/context-[0-n] and redirect inbound requests to that versioned directory.
After a while, you'll want to clean out that tmp directory because tomcat does not clean up after itself. It just keeps creating new directories after the app is reloaded.
This is not an issue under linux and it isn't recommended to use those options at all since linux doesn't have the same issues with locking resources and files.
Posted by Rick Fisk on March 09, 2007 at 05:28 PM MST #
This is appropriate when you want to deploy the entire war file. I love using it for production deployments.
Windows users should note that you are going to have problems with the tomcat deployer unless you set the context options antiResourceLocking and antiJarLocking to true in $CATALINA_HOME/conf/context.xml.
(See: tomcat FAQ on locking issues)
This is not recommended for production since it is a performance pig, but if you do not do the above, the jars from the previous app reload will not unload and you will have problems. I think the last comment on this thread alludes to the problem.
The workaround is to restart tomcat each time you deploy and this is definitely not optimal.
Even with the copy file approach on windows, you probably want to make sure the tomcat options are set to true.
The way that tomcat avoids windows locking issues is to copy the exploded war contents into tmp/context-[0-n] and redirect inbound requests to that versioned directory.
After a while, you'll want to clean out that tmp directory because tomcat does not clean up after itself. It just keeps creating new directories after the app is reloaded.
This is not an issue under linux and it isn't recommended to use those options at all since linux doesn't have the same issues with locking resources and files.
Posted by Rick Fisk on March 09, 2007 at 05:29 PM MST #
Posted by Sameer on November 25, 2007 at 09:13 AM MST #
Posted by Sameer on November 25, 2007 at 09:15 AM MST #
Posted by Patrick on June 02, 2011 at 08:27 PM MDT #