禁用log4j记录到控制台

Question

I have the following log4j.properties file:

# Direct log messages to a log file
log4j.appender.fileerror=org.apache.log4j.RollingFileAppender
log4j.appender.fileerror.File=C\:\\logs_eba\\loging-error.log
log4j.appender.fileerror.MaxFileSize=20MB
log4j.appender.fileerror.MaxBackupIndex=1
log4j.appender.fileerror.layout=org.apache.log4j.PatternLayout
log4j.appender.fileerror.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n 
log4j.appender.fileerror.threshold = WARN

# Direct log messages to stdout
#log4j.appender.stdout=org.apache.log4j.ConsoleAppender
#log4j.appender.stdout.Target=System.out
#log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
#log4j.appender.stdout.layout.ConversionPattern=%d{ABSOLUTE} %5p %c{1}:%L - %m%n

# Root logger option
log4j.rootLogger = WARN, fileerror

But my application keeps directing logs to my Console, it even shows logs at info level even though I defined WARN threshold.

For reference, this is how I get my Logging objects:

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

    private static final Logger log = LoggerFactory.getLogger(MyClass.class.getSimpleName());
log.warn("My log message");

Can it be related to my use of slf4j?

PS. I am using Spring + Hibernate as my architecture, and their logs are also being redirected to console.

Answer 1

Log4J by default looks up for log4j.properties file in the classpath and will consider the one found first. So if your application is depending on a library which itself is dependent on log4j and also provides log4j.properties of its own, then there is a chance that it is getting selected.

So I would recommend you to specify custom location for your properties using

java -Dlog4j.configuration=customName

Or use -Dlog4j.debug to find helpful info about the log4j configuration.

Answer 2

As mentioned in the answer by Narendra, this might be because one of your dependent libraries has a log4j.properties of its own, which is being picked up by the application (Your log4j.properties is being ignored). Ideally, this should not happen as most open source libraries do not include a log4j.properties file. They expect the calling module to provide one.

Find out which module this properties file is coming from. If it is an internal project that you have control over, you should remove the log4j.properties from it. If this is an external jar, try overriding your log4j.properties file over it. How you do this will depend on how you are deploying your jars together eg using maven, file copy etc.

PS: IMHO, no standard open source project should include its own log4j.properties file for this exact reason. If you are using such a library, may be its not very mature and you might want to have a look at alternatives.