Bug 32771 - Cannot undeploy/deploy misconfigured app after tomcat startup
Summary: Cannot undeploy/deploy misconfigured app after tomcat startup
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: Unknown
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-20 11:23 UTC by Gabriele Garuglieri
Modified: 2005-01-03 08:10 UTC (History)
0 users



Attachments
HostConfig patch (3.46 KB, patch)
2004-12-22 11:53 UTC, Gabriele Garuglieri
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gabriele Garuglieri 2004-12-20 11:23:04 UTC
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.
Comment 1 Remy Maucherat 2004-12-21 16:10:57 UTC
I don't find you convincing at all this time, sorry.
Comment 2 Gabriele Garuglieri 2004-12-21 17:00:08 UTC
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.
Comment 3 Remy Maucherat 2004-12-21 17:15:37 UTC
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.
Comment 4 Gabriele Garuglieri 2004-12-22 11:51:25 UTC
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.
Comment 5 Gabriele Garuglieri 2004-12-22 11:53:17 UTC
Created attachment 13820 [details]
HostConfig patch

Here's the patch that "should" solve what described above.
Comment 6 Remy Maucherat 2005-01-03 17:10:38 UTC
I have applied your patch, thanks.