[logback-user] Why DEBUG by default?

[lilyevsky]

I completely agree with you (and yes, there will be an slf4j error if there
is no logging framework in 
the classpath).

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.


Jeff Jensen-2 wrote:
> 
> I think you are trying to solve a problem that is not yours to solve.
> The consumers of your library are to solve that by properly
> configuring their logging system of choice.
> 
> Your library should have no logging implementation configured (e.g.
> Logback).  If I use your library and have no logging framework
> configured, slf4j will error and no logging will occur.  If that is
> not true with your library, then you have a library logging bug.  You
> must not configure Logback for your library because consumers of your
> library may choose a different one (or a different version).
> 
> 
> On Thu, Apr 28, 2011 at 8:08 AM, lilyevsky <lilyevsky at 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 at 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 at qos.ch
>>>> http://qos.ch/mailman/listinfo/logback-user
>>>>
>>>>
>>> _______________________________________________
>>> Logback-user mailing list
>>> Logback-user at 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 at qos.ch
>> http://qos.ch/mailman/listinfo/logback-user
>>
> _______________________________________________
> Logback-user mailing list
> Logback-user at qos.ch
> http://qos.ch/mailman/listinfo/logback-user
> 
> 

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