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.
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
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.
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@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
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@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
_______________________________________________ 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--tp31491746p31496781.html Sent from the Logback User mailing list archive at Nabble.com.
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
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
I'm puzzled that you would even think of fixing it this way when the right thing to do is just to make sure your production environment is configured properly and that it will always find a config file. How is it that you don't have complete control over your production environment configuration? Am I missing something? From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Leonid Ilyevsky Sent: Thursday, April 28, 2011 8:30 AM To: 'logback-user@qos.ch' Subject: [logback-user] Why DEBUG by default? 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.
participants (6)
-
Ceki Gulcu -
David Roussel -
David Tkaczyk -
Jeff Jensen -
Leonid Ilyevsky -
lilyevsky