There are two separate but related things in this thread. I mention
this because some of your questions seem to think some of my comments
are about one of them when they're actually about the other.
First, there is the current default behavior of log4j in the absence
of any configuration activity. I think the *intention* of the current
behavior is OK, but I also think there's a big bug in it (and it was
about that bug that I filed the bug report some days ago). Second, in
response to my comment on that, some have suggested that a different
default behavior is called for, and it is that specific proposal for
new behavior that I find completely puzzling.
ceki> The current behavior has a rationale behind it. By default, when
ceki> log4j is not configured and there are calls to a log4j loggers,
ceki> then log4j will emit a single log4j message complaining that
ceki> log4j is not configured. It is up to the user to either ignore
ceki> the log4j warning message or alternatively take the steps
ceki> necessary to configure log4j.
Yes, I think this is quite reasonable.
ceki> By elevating the default level of the root logger to ERROR,
ceki> there would be no such warning message. The user would not know
Well, I'm no expert on the mechanics of how this fits together inside
log4j. Couldn't you switch to ERROR or even FATAL level on the root
logger after you'd emited the warning about no configuration? There's
certainly a well-defined place to do that in the log4j code.
ceki> The current behavior let's the user know that logging is not
ceki> configured and then shuts up. It should not have an impact on
ceki> performance as no logging messages are actually being logged.
Unfortunately, the performance claim is not actually true in practice.
It can have a big impact on performance even though there are no
appenders. Since the root logger will stay configured at DEBUG, and
since we advise everybody not to worry how verbose DEBUG output is and
also not to worry about how hard it is to calculate it, there can be
quite a bit of it laying about. The usual defensive measure is no
good:
if (logger.isDebugEnabled())
{
logger.debug(calculatePiTo10000Digits());
}
The vast majority of my own logging at DEBUG level traces method call
entries (with parameters) and exits (with return values). The
"computation" consists mainly of concatenating String objects. That
isn't necessarily the most efficient thing to do, but it's probably
pretty typical of how much efficiency effort most people are willing
to put in for guarded DEBUG logging. "Hey, it's only DEBUG logging,
and it won't take a hit unless DEBUG is enabled."
I haven't tried to measure the relative performance hits of that
versus what it costs to send the results to non-existent appenders,
but the net effect is pretty daunting. My code can't easily tell the
difference between "DEBUG because somebody wants it" versus "DEBUG
because nobody configured anything", nor do I think my code should be
interested.
ceki> You are making it sound like log4j was incredibly difficult to
ceki> configure. Is that your perception of log4j?
I wouldn't say "incredibly difficult". I wouldn't say "easy", either.
I only say this because you asked. I wasn't particularly complaining
about the ease or difficulty of configuration ... only the pain of
needing explicit configuration versus not needing it at all in most
cases. When you're just some guy trying to run someone else's
software and you don't know anything much about log4j, it's a hassle
you don't need unless, well, you need it.
The performance bug of the current code is pain enought, but I was
talking about the case of the proposed change where all the DEBUG
logging would come streaming out onto the console if you ran some
application without configuring log4j. First, you'd have to figure
out it was log4j that did it to you (the current "no configuraton"
warning would likely be scrolled pretty far off the screen and not be
seen), and then you'd have to embark on a journey of self-education
about log4j.
But I think it has to be admitted, even when someone knows it's log4j
and wants logging turned on, it's a bit of a learning curve to figure
out what to put in a config file. I'm not especially complaining
about that, but I think it is a fact. I get questions all the time
from folks who do want to turn logging on for this or that. I used to
send them to the log4j web site and tell them to start with the
examples there. I don't do that any more since 75-80% of them came
back to me and asked me to create a config file for them anyhow. (If
I were writing an application instead of a library, I'd probably fix
that by giving command line options for various things, and my
application would translate that into appropriate log4j config. But
the question under discussion is what to do when the application
doesn't do that, for whatever reason.)
There is also a hassle factor in just needing to have a config file
available. Within application servers, it can be pretty tricky to get
these sorts of individual files to show up on the classpath.
ceki> Totally agreed. In the absence of any information about the user
ceki> environment, the default behavior is to say "hey log4j is not
ceki> configured". The alternative is to say nothing. I am not
ceki> convinced that the latter is wiser.
Sounds good to me (to keep giving the warning). I'm only complaining
about the performance impact of staying at DEBUG after you've done
that.
When I first added log4j DEBUG logging to my library, my QA department
sounded the alarm because some mystery change had immediately rendered
the product so slow as to be almost untestable. Though I immediately
suspected logging because I had just changed it, the log showed only
the two warning lines, so it took a lot of head-scratching to figure
out the root cause of the problem was. It was then, in self-defense,
that I put in my own check for no configuration. (To do that cleanly,
I pretty much had to do a wrapper which I hadn't previously needed.
Because I'm a library, I don't have a single entry like "main" for
such things.)
--
[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]
