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
_______________________________________________
Logback-user mailing list
[email protected]
http://qos.ch/mailman/listinfo/logback-user
