Tomcat 5.5.0-dev, Java 5, Win XP Pro SP2. I was hit by Bug 32729 so i've just downloaded source head from CVS and rebuilt the distribution to test its solution, but i think there are still problems in that area. Consider the following scenario (all using ant tasks): 1- deploy a .war containing a META_INF/context.xml with syntax errors 2- the .war is uploaded in webapps, the context.xml is extracted and copied in conf/Catalina/localhost, the application, as expected, is not correctly deployed and using list manager command it shows as stopped. 3- stop and restart tomcat 4- the application, as expected, won't deploy again, but this time it won't show either in list output and i cannot operate on it anymore. I mean that: a- i cannot undeploy it because the context path does not exist b- i cannot deploy. Even if a correct .war is uploaded in webapps the deploy task issue the following error: Cannot find message associated with key managerServlet.deployFailed c- if i manually delete [app].xml, the .war is uploaded, the context.xml is not extracted (like if Tomcat thinks it still exists), the deploy task issue the same error as before and the application still doesn't show up in list output. d- the same happen if i delete both conf/Catalina/localhost/[app].xml and .war from webapps e- if i stop Tomcat i get the following error, and it won't stop unless i kill it: INFO main org.apache.coyote.http11.Http11Protocol - Pausing Coyote HTTP/1.1 on http-8080 INFO main org.apache.catalina.core.StandardService - Stopping service Catalina java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:271) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:409) Caused by: java.lang.NullPointerException at org.apache.catalina.core.ContainerBase.removeChild(ContainerBase.java :883) at org.apache.catalina.startup.HostConfig.undeployApps(HostConfig.java:1 145) at org.apache.catalina.startup.HostConfig.stop(HostConfig.java:1117) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java :312) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(Lifecycl eSupport.java:119) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1051) at org.apache.catalina.core.ContainerBase.stop(ContainerBase.java:1063) at org.apache.catalina.core.StandardEngine.stop(StandardEngine.java:442) at org.apache.catalina.core.StandardService.stop(StandardService.java:51 2) at org.apache.catalina.core.StandardServer.stop(StandardServer.java:2044 ) at org.apache.catalina.startup.Catalina.stop(Catalina.java:586) at org.apache.catalina.startup.Catalina.start(Catalina.java:561) ... 6 more Sorry if i've been too much verbose, but i tried to give you as much details as i could, to help you understand the problem.
I don't find you convincing at all this time, sorry.
Remy, i'm not trying to convince anybody. I'm just reporting what is happening. I mean, Bug 32729 is solved. This is all new. I can deploy a misconfigured app and then i can undeploy it, but if i stop tomcat after deploying a misconfigured app, at restart happens what reported above. There is obviously the possibility that i'm doing something really stupid, but pls don't trash this before giving it a look. Thanks, Gabriele.
I misread the bug report, and I will not fix this, sorry. Avoid screwing up context.xml (and same with server.xml). Alternately, you can try to provide a patch if you feel you can fix it. Please do not reopen the bug report.
Well, Remy, just out of curiosity, when you consider a bug a bug? ;) > Avoid screwing up context.xml (and same with server.xml). In a perfect world i'd agree with you, but in a large company where, who's operating (and sometimes configuring) the application servers are not the same people who wrote the apps, to paraphrase a famous movie, "I've seen things, you humans can't even imagine...":) Anyhow, i tried to look into the source and i saw that the problem is that the app gets registered in the deployed Map when indeed the Context has not been built and there's no child with that name added to the host container. This makes the app no longer neither deployable nor undeployable and makes Tomcat behaving erratically at stop time. If i didn't overlook something, in org.apache.catalina.startup.HostConfig should be enough to check if the digester correctly built the Context and if has been added as a child to the host container before registering it into the deployed Map. In this case, the war deployer will have a chance later to try to deploy the app war, but since the context.xml is screwed up, the app will be registered but will remain stopped. This will allow to undeploy and redeploy it without problems. Obviously this will cause the context.xml to be parsed twice, and the log will show twice the SAXException messages, but i don't think this should be a problem, because now it is a recoverable and controlled situation. I'll attach a patch for this.
Created attachment 13820 [details] HostConfig patch Here's the patch that "should" solve what described above.
I have applied your patch, thanks.