I don't have a misunderstanding of the issues involved, I'm just wondering how common it is for our users to:
1. Use root logger to configure logging verbosity 2. Not want log4j output in those logs If so, they'd be -forced- to modify their log4j config file unless we provided some reasonable mechanism for enabling internal logging. Scott -----Original Message----- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: Tue 1/3/2006 10:14 AM To: Log4J Developers List Subject: Re: [COMPATIBILITY] Internal logging Quoting Curt Arnold <[EMAIL PROTECTED]>: > > On Jan 3, 2006, at 7:30 AM, Scott Deboy wrote: > > > Many people use root loggers, and now log4j's logging will be > > included in their application. > > > > Some folks will see this as an incompatibility - if they expected > > to be able to drop in 1.3 and have their log output look identical > > to how 1.2 behaved. > > > > It will be interesting to hear from users whether this is an issue. > > > > At a minimum, we need to provide a very clear example of how to > > keep log4j internal logging output out of their logs. > > > > We could consider programmatically defaulting log4j output off > > unless log4j.debug=true (if we choose to continue to support > > log4j.debug, which we probably should). > > > > Scott > > > There have been pretty frequent complaints on the mailing list, > particularly about inconsequential internal INFO messages showing up > in the application log. The log4j 1.2 unit tests also depend on the > output being free of log4j internal logging. > There has been some confusion about this, but keep in mind that most of it came from stuff that you couldn't turn off at all. This was logging that was coming from LogLog whether you had log4j.debug=false or legitimately turned it off in the logging configuration. The issue was in alphas up to, and including, Log4j-1.3alpha6. So, lets not confuse the two issues here and blow this problem out of proportion. These questions have dropped off significantly since alpha7. Keep in mind that if you set the root logger to be DEBUG or INFO, you are going to get bombarded with messages from every conceivable package using Log4j directly or via commons-logging. If one is inclined to do this, I think one is probably also inclined to turn off packages such as Jakarta-commons components and whatnot. With Log4j-1.3, the only surprise is that now they get Log4j internal logging being controled from their configuration, which didn't happen before (and this is a good thing, BTW). But it's hardly different from any other package. The quick fix is, obviously, to set the root logger to nothing lower than WARN and to specifically turn on other loggers rather than have them on by default. That's a basic Log4j education issue. > My thinking is that we should probably move the internal logging into > another branch of the hierarchy (that is loggers starting with > "internal." or "log4j.", not "org.apache.log4j") and set the default > threshold for the internal loggers to ERROR in the Hierarchy > initialization. > That's extra documentation and would surprise the heck out of me if it were implemented. Why should Log4j's own logging be treated specially? I expect that if I configure org.apache.commons to log to DEBUG, that I get debug messages out of Jakarta-commons components. Likewise, I expect that if I configure org.apache.log4j to log to DEBUG, that I get debug messages out of the Log4j component. This behavior is "least surprising" to me. Any other behavior is something I would forget and have to look up in the docs to determine what special case we applied for Log4j internal logging. Please don't change the way it is currently. -1 to changing the current behavior of internal logging. The onus to do so seems to be based on a misunderstanding of the issues involved. Jake --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
<<winmail.dat>>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
