[logback-user] Why DEBUG by default?
lilyevsky at mooncapital.com
Thu Apr 28 15:08:05 CEST 2011
I know how to make it find the configuration in various ways, this is not a
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 at mooncapital.com> wrote:
>> When logback cannot find configuration file anywhere, it sets the default
>> send everything to standard output and the level is set to DEBUG.
>> This creates a big problem in our production environment: super-verbose
>> 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
>> 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
>> This email, along with any attachments, is confidential and may be
>> 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
>> is strictly prohibited and this email and any attachments should be
>> 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
>> Moon Capital does not provide legal, accounting or tax advice. Any
>> regarding legal, accounting or tax matters was not intended or written to
>> 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 at qos.ch
> Logback-user mailing list
> Logback-user at qos.ch
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.
More information about the Logback-user