[JIRA] Created: (LBGENERAL-40) Default behaviour with no config
Default behaviour with no config -------------------------------- Key: LBGENERAL-40 URL: http://jira.qos.ch/browse/LBGENERAL-40 Project: logback-general Issue Type: Improvement Affects Versions: 0.9.14 Reporter: Paul Murray Assignee: Logback dev list One of our developers put logback in our project and didn't add a config file. This has killed our prod server for a week - 2 gig of hibernate debug messages per day, until I worked out WTF. Log4j handles this situation by emitting a single message and producing no more output. This is a pain in the butt in development - because you always have to put a log4j config somewhere while coding - but now I understand why: it's built to be usable safely in a production environment. I think you should consider altering the logback default behaviour to do what log4j does. Without that, it's a nervous business staging it on an internet-facing server. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBGENERAL-40?page=com.atlassian.jira.plugin.system... ] Ceki Gulcu commented on LBGENERAL-40: ------------------------------------- The reason for log4j not defaulting to the console is because not all platforms have a console. It has nothing to do with safety in the production environment. Log4j does not prevent the user from shooting oneself in the foot nor should it. It's the same with logback. While I am sorry for logback's behavior in the absence of a config file to have caused you trouble, I don't believe it merits correction.
Default behaviour with no config --------------------------------
Key: LBGENERAL-40 URL: http://jira.qos.ch/browse/LBGENERAL-40 Project: logback-general Issue Type: Improvement Affects Versions: 0.9.14 Reporter: Paul Murray Assignee: Logback dev list
One of our developers put logback in our project and didn't add a config file. This has killed our prod server for a week - 2 gig of hibernate debug messages per day, until I worked out WTF. Log4j handles this situation by emitting a single message and producing no more output. This is a pain in the butt in development - because you always have to put a log4j config somewhere while coding - but now I understand why: it's built to be usable safely in a production environment. I think you should consider altering the logback default behaviour to do what log4j does. Without that, it's a nervous business staging it on an internet-facing server.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBGENERAL-40?page=com.atlassian.jira.plugin.system... ] Ceki Gulcu resolved LBGENERAL-40. --------------------------------- Resolution: Won't Fix
Default behaviour with no config --------------------------------
Key: LBGENERAL-40 URL: http://jira.qos.ch/browse/LBGENERAL-40 Project: logback-general Issue Type: Improvement Affects Versions: 0.9.14 Reporter: Paul Murray Assignee: Logback dev list
One of our developers put logback in our project and didn't add a config file. This has killed our prod server for a week - 2 gig of hibernate debug messages per day, until I worked out WTF. Log4j handles this situation by emitting a single message and producing no more output. This is a pain in the butt in development - because you always have to put a log4j config somewhere while coding - but now I understand why: it's built to be usable safely in a production environment. I think you should consider altering the logback default behaviour to do what log4j does. Without that, it's a nervous business staging it on an internet-facing server.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBGENERAL-40?page=com.atlassian.jira.plugin.system... ] Ceki Gulcu edited comment on LBGENERAL-40 at 2/16/10 10:51 PM: --------------------------------------------------------------- The reason for log4j not defaulting to the console is because not all platforms have a console. It has nothing to do with safety in the production environment. Log4j does not prevent the user from shooting oneself in the foot nor should it. It's the same with logback. While I am sorry for logback's behavior in the absence of a config file causing you trouble, I don't believe it merits correction. was (Author: noreply.ceki@qos.ch): The reason for log4j not defaulting to the console is because not all platforms have a console. It has nothing to do with safety in the production environment. Log4j does not prevent the user from shooting oneself in the foot nor should it. It's the same with logback. While I am sorry for logback's behavior in the absence of a config file to have caused you trouble, I don't believe it merits correction.
Default behaviour with no config --------------------------------
Key: LBGENERAL-40 URL: http://jira.qos.ch/browse/LBGENERAL-40 Project: logback-general Issue Type: Improvement Affects Versions: 0.9.14 Reporter: Paul Murray Assignee: Logback dev list
One of our developers put logback in our project and didn't add a config file. This has killed our prod server for a week - 2 gig of hibernate debug messages per day, until I worked out WTF. Log4j handles this situation by emitting a single message and producing no more output. This is a pain in the butt in development - because you always have to put a log4j config somewhere while coding - but now I understand why: it's built to be usable safely in a production environment. I think you should consider altering the logback default behaviour to do what log4j does. Without that, it's a nervous business staging it on an internet-facing server.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[ http://jira.qos.ch/browse/LBGENERAL-40?page=com.atlassian.jira.plugin.system... ] Thorbjoern Ravn Andersen commented on LBGENERAL-40: --------------------------------------------------- I believe that the logback behaviour is much better than the log4j behaviour, namely that in the simplest possible case a default configuration is assumed which is reasonably useful to a developer. This means you can get up and running a new project without having to write a configuration file. How come you did not identify this issue in the testing phase?
Default behaviour with no config --------------------------------
Key: LBGENERAL-40 URL: http://jira.qos.ch/browse/LBGENERAL-40 Project: logback-general Issue Type: Improvement Affects Versions: 0.9.14 Reporter: Paul Murray Assignee: Logback dev list
One of our developers put logback in our project and didn't add a config file. This has killed our prod server for a week - 2 gig of hibernate debug messages per day, until I worked out WTF. Log4j handles this situation by emitting a single message and producing no more output. This is a pain in the butt in development - because you always have to put a log4j config somewhere while coding - but now I understand why: it's built to be usable safely in a production environment. I think you should consider altering the logback default behaviour to do what log4j does. Without that, it's a nervous business staging it on an internet-facing server.
-- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
participants (3)
-
Ceki Gulcu (JIRA) -
Paul Murray (JIRA)
-
Thorbjoern Ravn Andersen (JIRA)