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. 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? 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. 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. 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". 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. -- [EMAIL PROTECTED] (WJCarpenter) PGP 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
