We have log4j at the extension class loader level as well as at the application class loader level, and each have their own log4j.properties file.  This worked fine until we upgraded to a version of log4j that searches the Thread Context Classloader for log4j.properties.  Log4j at the extension classloader level started picking up our application's log4j.properties.  We have log4j.ignoreTCL=true coded, but this did not help.  Looking at the code, it looks like the loadClass method obeys this setting, but getResource does not.  To fix this, the section of getResource in org.apache.log4j.helpers.Loader should be changed from:
...
  	if(!java1) {
  	  classLoader = getTCL();
  	  if(classLoader != null) {
  	    LogLog.debug("Trying to find ["+resource+"] using context classloader "
  			 +classLoader+".");
...

to this (change is in first line only):

...
  	if(!java1 && !ignoreTCL) {
  	  classLoader = getTCL();
  	  if(classLoader != null) {
  	    LogLog.debug("Trying to find ["+resource+"] using context classloader "
  			 +classLoader+".");
...

This way setting log4j.ignoreTCL=true would make log4j only load properties from its current classloader and then also only load classes from the current classloader.