DO NOT REPLY [Bug 4138] New: - HttpProcessor threads have inconsistent ClassLoader state

[bu...@apache.org]

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

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4138

HttpProcessor threads have inconsistent ClassLoader state

           Summary: HttpProcessor threads have inconsistent ClassLoader
                    state
           Product: Tomcat 4
           Version: 4.0 Beta 6
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: Catalina
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: ruvinsky@yahoo.com


[Note that this is confirmed to be an issue for Tomcat 4.0b6, and is most 
likely an issue in the 4.0 final release.]

When an HttpProcessor thread gets created and first processes a request, its 
ClassLoader does not get set until midway in the pipeline invocation.  That is, 
the StandardHostValve changes the ClassLoader associated with the HttpProcessor 
thread to the WebappClassLoader just before it invokes the request's mapped 
context's pipeline.  However, it never restores the ClassLoader with the thread 
after the invocation of the context's pipeline has completed.

This results in an inconsistent ClassLoader state for that thread after the 
context's pipeline is finished being invoked.  The thread will still have the 
same WebappClassLoader for that context associated with it for all processing 
remaining for the existing request, as well as for the next request this thread 
will be assigned to handle (up until it changes the ClassLoader for a 
potentially different context when it invokes StandardHostValve).  
Consequently, this is a slight security issue, but more importantly, can lead 
to hard to reproduce bugs.

A simple fix for this problem would be to have StandardHostValve keep a 
reference to the current thread's ClassLoader just before it changes the 
ClassLoader for the mapped context to invoke it, and have it restore the 
original ClassLoader for the thread after it finishes invoking the context's 
pipeline.