On 28.04.2011 15:59, lilyevsky wrote:
I completely agree with you (and yes, there will be an slf4j error if there is no logging framework in the classpath).
As of SLF4J 1.6.0, if there is no slf4j binding present on the class path, slf4j will default to the nop implementation. From the SLF4J manual: As of SLF4J version 1.6.0, if no binding is found on the class path, then slf4j-api will default to a no-operation implementation discarding all log requests. Thus, instead of throwing a NoClassDefFoundError because the org.slf4j.impl.StaticLoggerBinder class is missing, SLF4J version 1.6.0 and later will emit a single warning message about the absence of a binding and proceed to discard all log requests without further protest. For example, let Wombat be some biology-related framework depending on SLF4J for logging. In order to avoid imposing a logging framework on the end-user, Wombat's distribution includes slf4j-api.jar but no binding. Even in the absence of any SLF4J binding on the class path, Wombat's distribution will still work out-of-the-box, and without requiring the end-user to download a binding from SLF4J's web-site. Only when the end-user decides to enable logging will she need to install the SLF4J binding corresponding to the logging framework chosen by the end-user.
However, my user(s) have different opinion about this issue, so I think my current solution is OK.
On the other hand, I still wonder what is the rational behind the DEBUG as default in logback. It seems to me that other frameworks such as log4j or java.util.logging have different behavior.
log4j also defaults to DEBUG. However, it does not install a console appender in the absence of a config file. Logback's behaves the way it does, in response to (log4j) popular demand. HTH, -- Ceki