While calling the method destory() on the StandardContext directly, it seems that the method destoryInternal() is called twice in the LifecycleMBeanBase, the two stacktraces are below : a. LifecycleMBeanBase.unregister(ObjectName) line: 191 LifecycleMBeanBase.destroyInternal() line: 73 ContainerBase.destroyInternal() line: 1109 StandardContext.destroyInternal() line: 5114 LifecycleBase.destroy() line: 271 ContainerBase.removeChild(Container) line: 963 ContainerBase.destroyInternal() line: 1106 StandardContext.destroyInternal() line: 5114 LifecycleBase.destroy() line: 271 ... b. LifecycleMBeanBase.unregister(ObjectName) line: 191 LifecycleMBeanBase.destroyInternal() line: 73 ContainerBase.destroyInternal() line: 1109 StandardContext.destroyInternal() line: 5114 LifecycleBase.destroy() line: 271 ...
When StandardContext is destroyed is destroys assets is manages which also have their own lifecycle. So you might be seeing those log messages. (Most likely StandardManager) Please reopen with more proof if this diagnosis is wrong.
(In reply to comment #1) > When StandardContext is destroyed is destroys assets is manages which also have > their own lifecycle. So you might be seeing those log messages. (Most likely > StandardManager) > > Please reopen with more proof if this diagnosis is wrong. I'm also seeing this on undeploying any app via the Manager application.
(In reply to comment #1) > When StandardContext is destroyed is destroys assets is manages which also have > their own lifecycle. So you might be seeing those log messages. (Most likely > StandardManager) > > Please reopen with more proof if this diagnosis is wrong. Not sure I understand your comments clearly. From the stack trace, while destorying the standcontext directly, it will check check whether its parent is null, if not, it will call the parent.removeChild() method, but removeChild method also try to destory the child. (As it does not known who calls the method). I will reopen the it, and try to attach a patch file. thanks.
Created attachment 26248 [details] Simple patch Try to provide a patch for it. Might not be proper, but it should be helpful to find what happens. Exception for the issue about double destory invocation, also, seems that Mapper.unregister action occurs before its internal destory (e.g. remove welcome resources).
I don't think the patch works. What I (think I) notice is StandardWrapperValve being destroyed for each servlet in the webapp. By default there is the default servlet and jsp servlet. If you enable ssi and cgi, I think you will see the call being done 4 times. Why? TBD.
(In reply to comment #5) > I don't think the patch works. > > What I (think I) notice is StandardWrapperValve being destroyed for each > servlet in the webapp. > > By default there is the default servlet and jsp servlet. If you enable ssi and > cgi, I think you will see the call being done 4 times. > > Why? TBD. Hmmm, the problem is not how many times the call is been done, currently, what I found is that the call is done on the same Context for more than more time. thanks.
Fixed in trunk and will be included in 7.0.5 onwards.