ys> The principle that a logging system should never hide/reject ys> logging statements unless explicitly configured to do so is very ys> strong. It trumps everything else a logging system should do, ys> pretty much, including good performance.
ps> I totally agree, when Log4j can detect that nothing has configured ps> it on the first log call, then the fail-safe method would be to ps> log everything to the console. Verbose or not, at least you know ps> what's happening in your application, and in some was the ps> verbosity will make you want to work out how to correctly ps> configure it...
I've been thinking about these opinions since they were posted a few days ago, and I can't get away from being puzzled by them. What rational purpose does this serve? There must be something pretty good in her because it has to overcome the obvious downside of putting a huge roadblock in front of a lot of folks who would not otherwise be annoyed at somebody's selection of a logging package.
The current behavior has a rationale behind it. By default, when log4j is not configured and there are calls to a log4j loggers, then log4j will emit a single log4j message complaining that log4j is not configured. It is up to the user to either ignore the log4j warning message or alternatively take the steps necessary to configure log4j.
By elevating the default level of the root logger to ERROR, there would be no such warning message. The user would not know that she had the option of configuring log4j to obtain information about the application through logging messages.
The current behavior let's the user know that logging is not configured and then shuts up. It should not have an impact on performance as no logging messages are actually being logged.
If nothing whatsoever is configured, log4j already mentions that fact. If someone is trying to figure out why logging isn't working, that is sufficient. They don't need their noses rubbed into extra megabytes that they didn't ask for. Are we trying to punish people until they submit to figuring out it's log4j that's doing things to them and then figure out how to make it stop?
You are making it sound like log4j was incredibly difficult to configure. Is that your perception of log4j?
More importantly: if they didn't ask for logging, they probably don't care much about it. Logging is extremely helpful, but it's not mission critical. It is almost by definition an after-the-fact phenomenon. Nobody should be monitoring patients' heartbeats with a DailyRollingFileAppender. An application that fails in some way is pretty unlikely to use logging as the only means of advertising that fact.
Agreed. But how is this related to the single warning message log4j emits when it is not configured.
If someone wants to run an application, they shouldn't have to learn about the details of logging before anything else, and they shouldn't have to have some loose file hanging around, just to get sane default behavior. Dumping an unending stream of unwanted DEBUG-level information to the console is not the way to please most of the people most of the time.
The user has to option to turn off logging altogether.
In Java, there is no "the console". In most web apps and appservers, the closest thing to "the console" ends up in some log file somewhere. It is not obviously visible to the person running the application. I've seen this firsthand more than once, and the reaction of the person it happens to is *not* "thank god they alerted me to the wonderful possibilities of logging configuration". It's more like "somebody around here is an idiot; I just don't know who it is, but I have a good idea".
Most idiots think that other people are idiots. A normal person could admit that the current behavior is the best one can do under a "zero-assumption" setting.
Applications that want a certain style or level of logging should look into that and configure what they want if the user doesn't. The authors of log4j have no way of knowing what various applications and various application users want, which is the whole point of its very flexible configuration. Authors of software components are in a sort of middle ground, but they can't in general know the nature of the calling applications or user environments.
Totally agreed. In the absence of any information about the user environment, the default behavior is to say "hey log4j is not configured". The alternative is to say nothing. I am not convinced that the latter is wiser.
I hope you find the above discussion a little more palatable then the previous explanations.
-- Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
