Re: Re-deploying webapps from war files
Mark D.Porter writes: Hello All, I'm working with the latest builds of tomcat (4.1.15) in hopes of moving from tomcat 3.3. One thing that seems to be missing in the 4.x line is a 'redeploy' feature for war files. In tomcat 3.3 I can setup my 'webapp' directory to 'look' for changes in a .war file and on a change event redeploy the application. This is a valuable feature for our development workflow and is sorely missed. If i am overlooking something obvious in the documentation of if this is an as yet 'undocumented feature' can someone please let me know. Thanks! Mark -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Hello Mark, is this not done in server.xml as an attribute for a context e.g. /examples? if not then use of http://localhost:8080/manager/remove?path=context and httpd://localhost:8080/manager/install?path=context should work. the latter, though manual, has the added advantage of remote invocation. hope this helps, david. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Re-deploying webapps from war files
Hi David! Thanks for your response - I've found that your second suggestion is automatable (is that a word?) via ant and as such is a good replacement for the functionality in Tomcat 3.3. However, it appears that these tasks rewrite server.xml and overwrite any ResourceParams elements that your re-deployed context may have contained. Is this a bug or am I mis-using these ant tasks/manager app functions. Thanks again, Mark On Tuesday, November 26, 2002, at 09:44 AM, David Brown wrote: Mark D.Porter writes: Hello All, I'm working with the latest builds of tomcat (4.1.15) in hopes of moving from tomcat 3.3. One thing that seems to be missing in the 4.x line is a 'redeploy' feature for war files. In tomcat 3.3 I can setup my 'webapp' directory to 'look' for changes in a .war file and on a change event redeploy the application. This is a valuable feature for our development workflow and is sorely missed. If i am overlooking something obvious in the documentation of if this is an as yet 'undocumented feature' can someone please let me know. Thanks! Mark -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Hello Mark, is this not done in server.xml as an attribute for a context e.g. /examples? if not then use of http://localhost:8080/manager/remove?path=context and httpd://localhost:8080/manager/install?path=context should work. the latter, though manual, has the added advantage of remote invocation. hope this helps, david. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Re-deploying webapps from war files
Mark D.Porter writes: Hi David! Thanks for your response - I've found that your second suggestion is automatable (is that a word?) via ant and as such is a good replacement for the functionality in Tomcat 3.3. However, it appears that these tasks rewrite server.xml and overwrite any ResourceParams elements that your re-deployed context may have contained. Is this a bug or am I mis-using these ant tasks/manager app functions. Thanks again, Mark On Tuesday, November 26, 2002, at 09:44 AM, David Brown wrote: Mark D.Porter writes: Hello All, I'm working with the latest builds of tomcat (4.1.15) in hopes of moving from tomcat 3.3. One thing that seems to be missing in the 4.x line is a 'redeploy' feature for war files. In tomcat 3.3 I can setup my 'webapp' directory to 'look' for changes in a .war file and on a change event redeploy the application. This is a valuable feature for our development workflow and is sorely missed. If i am overlooking something obvious in the documentation of if this is an as yet 'undocumented feature' can someone please let me know. Thanks! Mark -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Hello Mark, is this not done in server.xml as an attribute for a context e.g. /examples? if not then use of http://localhost:8080/manager/remove?path=context and httpd://localhost:8080/manager/install?path=context should work. the latter, though manual, has the added advantage of remote invocation. hope this helps, david. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] Hello Mark, i don't understand how u r overwriting server.xml? if used correctly, the ant build should only be generating a jar/war combination that when the server is restarted (or if u r using reloadable attribute) ur application context u have defined should overwrite ur application context directory under $TOMCAT_HOME/webapps and nothing else. u will need to examine much more closely what ur build.xml file is actually doing. sprinkle echo statements throughout ur build.xml to see what paths and files r being defined 4 for what actions (mkdir, copy, delete, javac, pathelements, etc.). tread carefully. ant is a great tool but will do only those instructions it receives from the user. hope this helps, david. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
