Where/how does log4j look for a log4j.properties f

问题:

I'm trying out log4j in a simple test app. I create a new Java project in eclipse and add the log4j JAR (v1.2.16) to my build path. I then create a simple class that prints Hello World. Then I use the log4j Logger class to log a info message. When I run the app, I see the log message, using what I assume is the default appender and layout. Great. What I'm having trouble with is adding my own configuration. This is what I've done:

Created a log4j.properties file with a custom appender and log level and placed it into the src folder (which upon compilation gets copied to the bin folder). Run the app - no change.

I try adding PropertyConfigurator.configure("log4j.properties"). Run the app - no change. No errors, but no change.

What do I have to do to get log4j to load my configuration file?

回答1:

For those that haven't RTFM, look under the heading Default Initialization Procedure, where you'll find the following:

The exact default initialization algorithm is defined as follows:

1. Setting the log4j.defaultInitOverride system property to any other value than "false" will cause log4j to skip the default initialization procedure (this procedure).
2. Set the resource string variable to the value of the log4j.configuration system property. The preferred way to specify the default initialization file is through the log4j.configuration system property. In case the system property log4j.configuration is not defined, then set the string variable resource to its default value "log4j.properties".
3. Attempt to convert the resource variable to a URL.
4. If the resource variable cannot be converted to a URL, for example due to a MalformedURLException, then search for the resource from the classpath by calling org.apache.log4j.helpers.Loader.getResource(resource, Logger.class) which returns a URL. Note that the string "log4j.properties" constitutes a malformed URL. See Loader.getResource(java.lang.String) for the list of searched locations.
5. If no URL could not be found, abort default initialization. Otherwise, configure log4j from the URL. The PropertyConfigurator will be used to parse the URL to configure log4j unless the URL ends with the ".xml" extension, in which case the DOMConfigurator will be used. You can optionaly specify a custom configurator. The value of the log4j.configuratorClass system property is taken as the fully qualified class name of your custom configurator. The custom configurator you specify must implement the Configurator interface.

回答2:

Argh. I discovered the problem was that eclipse had imported the wrong Logger class. It had imported java.util.logging.Logger which of course has it's own configuration that is different from log4j. Oh well, hope somebody else does this and gets it solved by reading this question.

回答3:

You can enable log4j internal debugging by setting the log4j.debug system property. Among other things, this will cause log4j to show how it is configuring itself.

You can try explicitly setting the URL to the configuration file with the log4j.configuration system property.

See also: this question.

回答4:

The problem may be in the classpath, if the classpath was defined.

The reason it wasn't loading (in my case): There was a conflicting log4j.properties file in one of my jars, and it was overloading the one in my classpath.

In short, if your log4j.properties file isn't loading, there might be another one somewhere else overriding it.

Just thought I'd throw this in too, in case anyone else runs into this. I just spent the last 5 hours trying to figure out why my default log4j.properties wouldn't load.

回答5:

log4j.properties should be in your classpath. The "src folder" which is copied to the "bin folder" (I assume you are speaking of a Eclipse setup here), normally belongs to your classpath, so it should be found (are you placing it at the top of the "src" folder, right?)

回答6:

I know this is a couple of months old, but I feel the need to point out that the scr folder isn't "copied" to the bin folder, nor is it part of your runtime classpath....(build path is not runtime classpath!). Eclipse compiles the source files in the src folder to the bin (or whatever you like) folder. It's the bin folder that is part of your runtime classpath.

Just wanted to point this out as these threads are often read by very junior programmers as well, and I'm always frustrated that most of them don't grasp the finesse of the Java classpath, and hence make avoidable mistakes against it.