At 12/3/2002 09:09 AM, you wrote:Actually, this isn't working the way I thought it was/would. By doing a remove/install of the app, TC is running from the .war file vs. unpacking the .war and running the app from the subdirectories. This works, but (as we discovered) if/when TC is restarted, the result is the 'old' version of the app running from the subdirectory because we didn't remove it.Mark writes:I have an expanded-war app where it will initially auto-deploy (ie. expand the directories under /webapps), but not able to get it to hot redeploy after changes are made. By 'hot', I mean automatically have a new.war file re-expanded without restarting Tomcat.Hello Mark, i u r using: http://localhost:8080/manager then this works 4 me: http://localhost:8080/manager/remove?path=<webapp> and http://localhost:8080/manager/install?path=<webapp> where "<webapp>" means ur application context generated from ur .war. u must "remove" then "re-install" using the /manager webapp and "hot" deploy works w/o bouncing tc. hope this helps, david
If I make changes to the app and create a new.war file, the only way I can get it to re-deploy is if I remove the existing directory under webapps then shutdown/restart Tomcat. If I delete the directory and move a new .war file into /webapps while TC is running, it's not automatically expanded. I've tried removing the app via the TC manager first, but it still won't auto-deploy. If I simply rename the .war file while it's in the /webapps directory, it's immediately deployed with the new directory name w/o restarting TC. In a nutshell, if I use the same .war name, it won't redeploy unless I restart TC. I'm using the out-of-the-box server.xml, where unpackWARs="true" and autoDeploy="true" for localhost.
Is there no way to 'hot' deploy an existing app the way I'd like without restarting Tomcat? I've looked at the documentation and searched the archives/Internet. In almost all cases, the last step is to 'restart Tomcat'. My goal is to have automatic continuous-integration, including auto-deployment. Having to manually restart TC each time throws a wrench into that process.
Thanks
Mark
--
--
Maybe we're trying to mix-match or doing something real unconventional (dumb), but the question/problem seems pretty straightforward: given a previously-deployed unpacked app called 'myapp', can Tomcat refresh the contents of the /webapps/myapp subdirectories automatically from a new .war file? The only way we've been able to do that is to shutdown TC, delete the /myapp directory and restart TC, allowing it to unpack the .war and re-create the /myapp directory structure.
Based on what I've found, it looks like we should use one of these 2 methods for hot-deployment:
1) Run the app from the .war vs. unpacking it, and use remove/install.
2) Replace changed files in the /myapp directory structure, and use reload.
Both work but I'm curious what method is typically used/recommended, or whether it's just personal preference. Thanks.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Hello Mark, acutally u need to do both 1 and 2 as i do but i guess i left out part of my automation process which is: ant. this little (no pun intended) but very powerful development tool is indespensible as part of my development structure. the ant tool basically automates the phsysicall removal of the "old" webapp directory as it completes the compile, generation and deployment of all my .ear, .war and .jar files. i run ant with 2 or more (depending on the depth of the webapp directories) build.xml files and 2 scripts namely: cleansite.sh and buildsite.sh (w/ controlling parms). these tools completely build or rebuild webapp/site, tear down the old and replace w/ the new and all is immediately accessible and tc never knows the difference. i can make edit changes or create whole new application contexts and webapp directory sites w/ these tools running all in the public no less (not so much brag i just can't afford a separate dev server). hope this helps, david.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
