Yea I can see where that could be a problem, although using Resin I haven't run into that particular behavior. Maybe I should rethink that strategy for production events...works great for development and testing however.
-----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Friday, February 28, 2003 4:04 PM To: Struts Users Mailing List Subject: RE: deploy with ant, best practices On Fri, 28 Feb 2003, Jaye Bass wrote: > Date: Fri, 28 Feb 2003 13:06:33 -0600 > From: Jaye Bass <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: 'Struts Users Mailing List' <[EMAIL PROTECTED]> > Subject: RE: deploy with ant, best practices > > My ant targets build directly into my webapp directories...the root > location is set in an env variable. This really seems to work for us on > a variety of systems (linux, windows, and occasionally macs) from > development to ultimate deployment and maintenance. > The only aspect of this I'd be concerned about is if Tomcat happened to try to auto-deploy your app while it was being compiled, but is currently incomplete. You might end up with some mysterious issues. Craig > -----Original Message----- > From: Dan Allen [mailto:[EMAIL PROTECTED] > Sent: Friday, February 28, 2003 1:30 AM > To: [EMAIL PROTECTED] > Subject: deploy with ant, best practices > > I have been studying ant very thoroughly over the past two days, and > I completely understand the file from top to bottom, including how > to reload the application using the <reload> tag imported from > org.apache.catalina.ant.ReloadTask. However, I am stuck on an > issue. > > Assuming that I follow the techniques from the book Struts Kick > Start, I create a development tree such as > > ${app.home} > /build > /deploy > /object > /src > /lib > /web > /WEB-INF > /META-INF > > then the actual target tree (under tomcat/webapps) is the typical > > ${app.name}.war > ${app.name} > /WEB-INF > /WEB-INF/lib > /WEB-INF/classes > /META-INF > > Okay, now stay with me here. Assume that I currently have the > application running under tomcat. If I build the .war file from the > build/ directory and place it into ${app.home}/deploy, then copy > it to ${app.name}.war under tomcat/webapps, it isn't going to > automatically expand over the current running tree. It just sits > there until I kick tomcat (restart it) after deleting the running > application directory. > > So what I did instead was I made the build/ directory the actual > running application directory so it just copied over the "live" > files directly as they were updated by javac. Then a simple > "reload" would cause the application to start using the updated > files. > > The question on the table is as follows. How do you get tomcat to > expand an updated .war file over a currently running application > before you reload it? It seems wrong to have the "live" application > the target of my build process. > > The goal here is to update the running application without having to > restart tomcat and without having to use the running application as > the target of the build process. I want to be able to copy the > updated .war file into the tomcat/webapps folder and have it expand > it over the running application files. Is this unreasonable to > expect this? How does everyone else do it. Surely you are not > restarting tomcat all day. > > Dan > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Daniel Allen, <[EMAIL PROTECTED]> > http://www.mojavelinux.com/ > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > "I am the GOD.....the GOD...of house!" > -- Leeloo > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]