Bug 47967 - log4j.ignoreTCL should apply to the getResource method in addition to the loadClass method of org.apache.log4j.helpers.Loader
log4j.ignoreTCL should apply to the getResource method in addition to the loa...
Status: RESOLVED FIXED
Product: Log4j
Classification: Unclassified
Component: Configurator
unspecified
Other AIX
: P2 critical
: ---
Assigned To: log4j-dev
:
: 48012 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2009-10-08 13:18 UTC by vonnahme.paul
Modified: 2009-11-08 13:00 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description vonnahme.paul 2009-10-08 13:18:19 UTC
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.
Comment 1 Curt Arnold 2009-10-08 21:23:03 UTC
Committed rev 823403.
Comment 2 Curt Arnold 2009-11-08 13:00:54 UTC
*** Bug 48012 has been marked as a duplicate of this bug. ***