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 --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]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
