logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <c...@qos.ch>
Subject RE: How Do I Find Out If log4j Has Been Configured?
Date Sun, 09 May 2004 13:15:28 GMT
At 12:26 AM 5/7/2004, WJCarpenter wrote:
>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: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org


Mime
View raw message