[logback-user] Why DEBUG by default?
ceki at qos.ch
Thu Apr 28 17:05:58 CEST 2011
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.
More information about the Logback-user