logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject RE: [COMPATIBILITY] Internal logging
Date Tue, 03 Jan 2006 21:49:22 GMT
Quoting Scott Deboy <sdeboy@comotivsystems.com>:

> 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

2. Not want [name your package here] output in those logs

Best Solution ...

<logger name="com.mycompany.mypackage">
    <level value="DEBUG"/>

<!-- suppress verbosity by default -->
   <level value="WARN"/>

Alternate solution...

<!-- multiple instances of verbosity suppression loggers -->
<logger name="[some package to suppress]">
    <level value="WARN"/>

<!-- enable verbosity by default -->
   <level value="DEBUG"/>

> If so, they'd be -forced- to modify their log4j config file unless we
> provided some reasonable mechanism for enabling internal logging.

Again, this is simple education.  If one is willing to take the initiative to
upgrade to Log4j-1.3, knowing that there are a number of changes/additions
(with one of those changes being Log4j internal logging), I think we can expect
that they are willing to update their config file.  This is a minor pain (if one
insists on calling it pain).  Let's not make exceptions to normal behavior
simply to avoid the slight surprise that people may initially have that Log4j
actually uses itself to log in the same way everything else uses Log4j to log. 
This problem is not unique.  It's the same problem for any given package that
you can think of that uses Log4j to log messages.


> Scott
> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@visi.com]
> Sent: Tue 1/3/2006 10:14 AM
> To: Log4J Developers List
> Subject: Re: [COMPATIBILITY] Internal logging
> Quoting Curt Arnold <carnold@apache.org>:
> >
> > 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: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message