Follow-up to discussion on the jgroups-dev list of issue where threads created by JGroups, particularly pool threads, inherit their TCCL from whatever thread triggers their creation. This can leak application classloaders in an environment where different applications share JGroups resources.
Attached is a patch for this, against the 2.6 branch. We can use this to discuss whether this is worth fixing in JGroups. I have a fix in JBoss AS, although I'm concerned it could prove fragile over time.
The patch is pretty simple, except for TCLAction, an abstraction used to deal with the presence or absence of a SecurityManager. I also tried to handle a J2ME case where SecurityManager, or even the ClassLoader class, don't exist. Not sure if that will work, just an effort.
Patch includes a unit test based on the one in JBoss AS. Hasn't really been properly adapted to all the stuff going on in the JGroups test environment, but it works.
- is duplicated by
-
JGRP-764 Thread context classloaders: add ability to set TCCL when thread is created and unset it when thread is released
- Resolved