New member to the list, long time Tomcat user. Recently upgraded from 4.x to 5.x.
I am running Tomcat version 5.0.19 on Windows XP SP1 (patched up to date) with unpackWARs="true" and autoDeploy="true".
I've encountered a strange behavior that occasionally occurs when reeploying a web-app that was contained in a .WAR.
At times Tomcat leaves certain .jar files in the WEB-INF/lib of the unpack folder when undeploying the .WAR. The remaining .jar(s) are share locked by the OS and can not even be deleted manually until Tomcat is stopped completely.
Naturally, Tomcat can't redeploy the .WAR afterwards.
when re-deploying it apparently fails to expand the new .WAR,
and the log contains:
INFO: Missing application web.xml, using defaults only StandardEngine[Catalina].StandardHost[localhost].StandardContext[/blog-app]
But this is to be expected if Tomcat can't override the folder.
This seems to happen specifically with mail.jar (JavaMail API 1.3.1) if a related exception occured during the lifetime of the web-app -- i.e. while sending mail (smtp server not responding, etc).
If no exception occured, the .WAR will undeploy completely and there would be no problem redeploying.
This behavior also happened to me with tyrex-1.1.jar (transaction manager from the exolab folks) even when no tyrex classes has been used AFAIK.
At first I thought perhaps it was a classloader issue due to class sharing, but as far as I could find the JavaMail API classes are not part of Tomcat. Note that aside from the default .WARs that come with the default installation, only the problematic .WAR is contained.
Am I missing something substantial, or could this possibly be a bug?
Are there any logs I can turn on to see what happens during the undeploy process?
Any clue would be greatly appreciated,
Thanks in advance, Tal Rotbart
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
