As slf4j does not deal with configuration there is no way to deal with this at the slf4j level. 

Logging at debug level is the correct default. It always used to annoy me that log4j didn't log anything if it couldn't find any config. 

If the 'customers' of your framework know enough to put logback on the classpath but yet don't know how to configure it, then my mind boggles. Do they also complain to you when they run out of disk space?

David

On 28 Apr 2011, at 14:08, lilyevsky <lilyevsky@mooncapital.com> wrote:


Thanks Jeff,

I know how to make it find the configuration in various ways, this is not a
problem.
My problem is different: how to make my code behave in a sensible way when
it is not under my control.

Here is the scenario. I write some library that will be used by others, I
use slf4j for my logging,
and I have debug output in many places.
I would have more control on the library if I produced it as a jar (ideally
built by maven), but
unfortunately in current situation it may be used on the source code level.
I mean, the other
developer will compile it together with the other stuff, using naked javac.

After that, at runtime, if the configuration is not provided, the debug
problem comes up.

As I mentioned, I have the solution (default configuration with WARN level
is hard-coded), but I don't
quite like it because now my code suddenly is aware of logback, instead of
just pure slf4j.

Basically, my complaint is this: why by default logback goes to DEBUG level,
not to INFO
or even WARN?

At least, this could be controlled by a Java system property.



Jeff Jensen-2 wrote:

Place a Logback XML config file on the classpath.  I've done this in
many apps without a problem.  You must've done this and it's not found
(is that what you mean by "cannot find configuration file anywhere")?


On Thu, Apr 28, 2011 at 7:29 AM, Leonid Ilyevsky
<lilyevsky@mooncapital.com> wrote:
When logback cannot find configuration file anywhere, it sets the default
to
send everything to standard output and the level is set to DEBUG.



This creates a big problem in our production environment: super-verbose
log
that is even difficult to look at.



My solution was to create a small wrapper using JoranConfigurator. This
works great, and I can do whatever I need.



However, here is the downside: my code is no longer ignorant of logback.
Previously it was purely slf4j everywhere, but now every class is
indirectly
dependent on logback stuff (though it is limited to 2 lines in every java
file). This defeats the purpose of slf4j as pure facade.



Is there any better solution?

Our problem is, we need to guarantee that no matter what happens in the
logging layer, it should never go wild and produce all that debugging
noise.



________________________________
This email, along with any attachments, is confidential and may be
legally
privileged or otherwise protected from disclosure. Any unauthorized
dissemination, copying or use of the contents of this email is strictly
prohibited and may be in violation of law. If you are not the intended
recipient, any disclosure, copying, forwarding or distribution of this
email
is strictly prohibited and this email and any attachments should be
deleted
immediately. This email and any attachments do not constitute an offer to
sell or a solicitation of an offer to purchase any interest in any
investment vehicle sponsored by Moon Capital Management LP (“Moon
Capital”).
Moon Capital does not provide legal, accounting or tax advice. Any
statement
regarding legal, accounting or tax matters was not intended or written to
be
relied upon by any person as advice. Moon Capital does not waive
confidentiality or privilege as a result of this email.

_______________________________________________
Logback-user mailing list
Logback-user@qos.ch
http://qos.ch/mailman/listinfo/logback-user


_______________________________________________
Logback-user mailing list
Logback-user@qos.ch
http://qos.ch/mailman/listinfo/logback-user



--
View this message in context: http://old.nabble.com/Why-DEBUG-by-default--tp31491746p31496279.html
Sent from the Logback User mailing list archive at Nabble.com.

_______________________________________________
Logback-user mailing list
Logback-user@qos.ch
http://qos.ch/mailman/listinfo/logback-user