As a side effect of my commit, I think I found a bug in StandardContext.bindThread() and unbindThread() methods in both tomcat 6 and 7 : - the methods should be symmetrical : unbindThread should restore the Thread CCL after calling DirContextURLStreamHandler.unbind() and ContextBindings.unbindThread() - StandardContext.bindThread() should call DirContextURLStreamHandler.bindThread() instead of DirContextURLStreamHandler.bind() - StandardContext.unbindThread() should call DirContextURLStreamHandler.unbindThread() instead of DirContextURLStreamHandler.unbind()
oops, forgot the link to my initial commit that revealed the bug : http://svn.apache.org/viewvc?rev=1044145&view=rev
fix committed on trunk : http://svn.apache.org/viewvc?rev=1044746&view=rev
Moving to 6 now it is fixed in 7.
patch proposed for tomcat 6
Looking at r1044746 and the patch proposed for TC6, I think that that replacement of s/DirContextURLStreamHandler.bind(/DirContextURLStreamHandler.bindThread(/ s/DirContextURLStreamHandler.unbind(/DirContextURLStreamHandler.unbindThread(/ is wrong. See DirContextURLStreamHandler#get(). The difference is when a web application starts a child thread. That thread inherits TCCL from its parent and thus DirContextURLStreamHandler will recognize it when using CL-binding, but will not if thread-binding is used.
Actually the TCCL is properly bound in DirContextURLStreamHandler#clBindings when the application is started : DirContextURLStreamHandler.bind(ClassLoader, DirContext) is called from WebappLoader.startInternal() which itself is called during StandardContext.startInternal() (StandardContext.java rev 1044747 line 4863) Before my fix, it was "pure luck" that the TCCL was still bound after StandardContext.startInternal() : it only worked because the TCCL was reverted _after_ calling DirContextURLStreamHandler.unbind() so that the latter tried to remove a classloader that had not been bound previously, thus leaving the webapp classloader properly bound.
(In reply to comment #6) OK, I understand it now. WebappLoader indeed manages that binding.
Fixed in 6.0.x and will be included in 6.0.30 onwards.