DO NOT REPLY [Bug 38795] - StandardContext doesn't always reset thread's contextClassLoader

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=38795>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=38795





------- Additional Comments From darryl@darrylmiles.org  2006-03-01 14:23 -------
I read with interest your report and wonder if some other infrequenct problems
that I've experienced in the past maybe related to this section of code.


Would it make sense to use code like:

try { filterStop(); } catch(Exception e) { e.printSomething(); }

try { listenerStop(); } catch(Exception e) { e.printSomething(); }

etc... the idea being that each invokation to web-application code (from TC
internal code) should not be able to upset TCs shutdown mechanism and should try
a best effort to do everything properly.  Then at the end of it all just cut
away the web-app and cleanup.

My suggestion above is making a huge presumption that filterStop() invokes all 
the active javax.servlet.Filter#destroy() filters under the context to shut them
down.  Looking briefly through that particular path I can't see any trapping of
web-app exceptions.

StandardContext#filterStop()
 ApplicationFilterConfig#release()
  javax.servlet.Filter#destroy()

In the absense of any mandated behaviour (from JSRs) I would think the
exceptions are best caught in ApplicationFilterConfig#release() so that other
filters within the same context get called (call it "best effort").  I dont
understand the org.apache.catalina.SecurityUtil stuff in the same place, maybe
there is other ways to invoke javax.servlet.Filter#destroy() that need the same
treatment.


Its very important that TCs internal accounting state can never be disrupted no
matter how badly a web-app behaves.  An audit of this code to wrap the whole
section with a suitable finally clause to ensure TCs internal state retains its
integrity makes perfect sense to me.  The two things together can only increase
robustness with minimal cost.


Possibily related bug reports discussing web-app generated Exceptions during
context shutdown:

Bug #37498

Bug #36250 => Comment #14
(http://issues.apache.org/bugzilla/show_bug.cgi?id=36250#c14)


-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org