Better to always download as your first try, the most recent version from the developer’s site I had the same error message you had, and by downloading the jar from the above (slf4j-1.7.2.tar.gz most recent version as of 2012OCT13), untarring, uncompressing, adding 2 jars to build path in eclipse (or adding to classpath in comand … Read more
Spring uses commons-logging which auto-detects the logging framework to use. There are various ways to tune which logging framework will be chosen so the first thing to do is to make sure commons-logging binds to log4j. To do that, start your application with an additional flag -Dorg.apache.commons.logging.diagnostics.dest=STDOUT that will output the result of the discovery … Read more
It’s very easy and not a performance issue anymore. There are two ways documented in the SLF4J manual. There are also precise examples in the Javadocs Add jul-to-slf4j.jar to your classpath. Or through maven dependency: <dependency> <groupId>org.slf4j</groupId> <artifactId>jul-to-slf4j</artifactId> <version>1.7.0</version> </dependency> If you don’t have logging.properties (for java.util.logging), add this to your bootstrap code: SLF4JBridgeHandler.removeHandlersForRootLogger(); SLF4JBridgeHandler.install(); … Read more
One approach I have used successfully is to use slf4j as my primary logging API. I then have slf4j bind to log4j. 3rd party dependencies using other frameworks (like JUL) can be bridged to slf4j.
Go ahead: program to the log4j2 API instead of slf4j It’s safe: the Log4j2 API offers the exact same guarantees as slf4j – and more. Now that Log4j2 itself is separated into an API and an implementation module, there is no longer any value in using SLF4J. Yes, it is good engineering practice to keep … Read more
It’s either through system property -Dorg.slf4j.simpleLogger.defaultLogLevel=debug or simplelogger.properties file on the classpath see http://www.slf4j.org/api/org/slf4j/impl/SimpleLogger.html for details
Yes, this is a common problem I’ve run into as well. There are a few workarounds (like manually setting it, as described), but ideally you want a solution that Sets the MDC consistently; Avoids tacit bugs where the MDC is incorrect but you don’t know it; and Minimizes changes to how you use thread pools … Read more
Look to https://github.com/jboss-logging/jboss-logging/blob/master/src/main/java/org/jboss/logging/LoggerProviders.java: static final String LOGGING_PROVIDER_KEY = “org.jboss.logging.provider”; private static LoggerProvider findProvider() { // Since the impl classes refer to the back-end frameworks directly, if this classloader can’t find the target // log classes, then it doesn’t really matter if they’re possibly available from the TCCL because we won’t be // able to find … Read more
Resolved by adding the following exclusion in the dependencies (of pom.xml) that caused conflict. <exclusions> <exclusion> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> </exclusion> </exclusions>
You can add/remove Appender programmatically to Log4j: ConsoleAppender console = new ConsoleAppender(); //create appender //configure the appender String PATTERN = “%d [%p|%c|%C{1}] %m%n”; console.setLayout(new PatternLayout(PATTERN)); console.setThreshold(Level.FATAL); console.activateOptions(); //add appender to any Logger (here is root) Logger.getRootLogger().addAppender(console); FileAppender fa = new FileAppender(); fa.setName(“FileLogger”); fa.setFile(“mylog.log”); fa.setLayout(new PatternLayout(“%d %-5p [%c{1}] %m%n”)); fa.setThreshold(Level.DEBUG); fa.setAppend(true); fa.activateOptions(); //add appender to any … Read more