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