[logback-user] Why DEBUG by default?

[Ceki Gulcu]

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