Steps to reproduce: 1. autodeploy a web application by defining its context in server.xml 2. start the Tomcat server 3. use the Tomcat Manager to undeploy the application You will get the "OK - Undeployed application at context path /WebApplication" message, but the application will NOT be undeployed, it will be only stopped. If you try to stop the server after that, it will fail! I have used the shared installation (CATALINA_BASE dir), but I guess this won't work for standalone Tomcat isntallation either.
One more thing, this works for Tomcat 5.0.x.
In 5.5, the manager will only handle contexts deployed by the autodeployer. Please don't insist for it to behave in a different way, it will not happen. The other part of the bug has been fixed already.
So you claim that it is 'as designed' to restrict undeploy by manager of autodeployed applications? (I'm OK with that) But why the report is: "OK - Undeployed", if it is not true! I'd expect different result message at least (it could be probably downgraded).
Hacking in contexts using server.xml is not recommended. I do not see any reason to address this non issue.
I'm OK with not recommend using server.xml, but it is still part of product, therefore valid issue, although with lower priority.
I do not insist on this being considered as a serious issue, especially if the stopping has been fixed. However, I do not agree it is a "non issue". Defining context in the server.xml is a valid usecase, although not recommended and ugly, but it is still valid. I would expect the Tomcat Manager to behave reasonably which is returning something like "FAIL - Application cannot be undeployed..." and not claiming it was undeployed successfully, if it was not. Remy, please note that I've filed this issue in attempt to improve the Tomcat user experience. This usecase is not what I would personally do. However, users who are upgrading from erlier versions (3.x.x or 4.x.x) are often used to it and they would surely consider this as an issue. Btw, if this issue should be closed, it should be cloased as WONTFIX and not as INVALID. Anyway, thanks Remy for fixing the other issue!
I have fixed this by disabling undeploy for contexts defined in server.xml This fix will be in 5.5.20 onwards