ys> I'm -1 on changing this: in the absence of explicit configuration, ys> it's better to have more information than less, so the current ys> default is best. Obviously there'll be scenarios where it's ys> expensive and/or ill-fitting, but those people should explicitly ys> configure log4j. The default config of a logging system should ys> never hide/reject logging statements.
I don't understand your comments. With the current defaults there are no appenders, so *no* information is logged except a single console message to the effect that there was no configuration. Regardless of what the defaults are, that's all that anyone can see (and when that tumbles into an appserver logfile, it's easily overlooked, especially since everything in the application still works). Thus, in a sense, the default configuration does hide logging. It's a fine thing to say that an application that uses log4j must always configure log4j (I don't agree with that argument, but it's at least reasonable). What if you're using log4j in a library? It's not up to you (the library writer) to decide what configuration the calling application wants. You're in effect saying that every component using log4j should go through the little "is it already configured?" dance that was just discussed on this list, because you can't know how your library will be combined with other components, and you can't depend on somebody else checking the configuration. What is the advantage of logging at DEBUG level if there are no appenders? -- [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]
