Determining the active log4j.properties file

[Rick Herrick]

I'm having a problem when starting up Tomcat that's led me to a more philosophical question. The immediate problem is that Tomcat starts up with the log4j logging level set to DEBUG. This means I get EXTREMELY verbose information from places I quite frankly don't want to know about. The problem is that I've gone through and located EVERY log4j.properties file that I can find and renamed them all and yet I still get this behavior. This means that I can't turn this level down.

So the philosophical question is, how can I determine which version of a particular resource file is getting picked up by something? I'd like to solve the immediate problem of turning down my debug level and the longer-term problem of knowing which properties file Tomcat is getting its hands onto. I really think it'd be awesome if the first thing log4j did is spit out which file it was using (if it can do resolve that, anyways).

And yes, I've tried looking along the explicit classpath set in the catalina start-up script (batch file in my case, since I'm on W2K).

Any info would be greatly appreciated.

[Guy Allard]

Some open source projects have been known to put a log4j.properties file in their jar.

It is a very bad practice, but I have seen it.

Guy

[David Harkness]

I haven't tried this, but what about ClassLoader.getResource("/log4j.properties")? It returns a URL, hopefully containing the name of the JAR file.

ClassLoader cl = Thread.currentThread().getContextClassLoader();
URL loc = cl.getResource("/log4j.properties");
System.out.println("Search and destroy --> " + loc);

[Rick Herrick]

Guy,

I had thought of that and actually ran a batch "jar tf" on all of the jar files that I could find on the classpath. No luck.

David,

A most excellent suggestion that yielded useful information that, unfortunately, hasn't helped me solve the problem. I modified your code a bit to walk all the way up the class loader hierarchy:

ClassLoader cl = Thread.currentThread().getContextClassLoader();
 
while(cl != null)
{
   URL loc = cl.getResource("/log4j.properties");
   System.out.println("Search and destroy --> " + loc);
   cl = cl.getParent();
}

I find that the only log4j.properties that is available is loaded by the web app classloader. So I've tried to add it by force at various points in the classpath, to no avail. I've tried adding this same discovery code to Tomcat by disassembling Bootstrap.class and replacing it in the jar, but there I see no evidence of the log4j.properties resource being added to the catalinaLoader, commonLoader, or sharedLoader, even though I have it in the classpath. The complication is that it doesn't seem like anything ELSE is getting added to the classpath, so something very strange is going on.

I'll post a follow-up when I figure out what's going on!

[Rick Herrick]

OK, the important change was removing the "/" from the getResource() call:

// This one gets null
commonLoader.getResource("/log4j.properties");
 
// This one finds the properties file
commonLoader.getResource("log4j.properties");

What's interesting about that is that, in my Struts action class where I initially placed David's sample code, the version with the leading slash did work. So that's strange. But OK.

Now the next strange thing is that I find which log4j.properties is used and even after I turn all of the settings in that file to FATAL, I still get tons of debug messages. What seems to unite these, though, is that they're all Struts messages. Is there some sort of Struts debug or tracing facility separate from log4j? It uses the commons logging stuff, I know that, but doesn't that just grab whatever's around, with a strong prejudice for log4j?