You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Paul Smith <Pa...@lawlex.com.au> on 2004/05/03 00:12:12 UTC
RE: How Do I Find Out If log4j Has Been Configured?
> Hi,
> You know, though, I would argue that in the absence of any
> configuration
> all logging statements should be output to the console. So
> in a sense,
> I'd like to have BasicConfigurator.configure called
> automatically on the
> first logging statement if no other configuration has been done. Then
> you'd get the current warning that log4j hasn't been configured, and
> from that point on all output at DEBUG level to the console. The
> principle that a logging system should never hide/reject logging
> statements unless explicitly configured to do so is very strong. It
> trumps everything else a logging system should do, pretty much,
> including good performance.
I totally agree, when Log4j can detect that nothing has configured it on the
first log call, then the fail-safe method would be to log everything to the
console. Verbose or not, at least you know what's happening in your
application, and in some was the verbosity will make you want to work out
how to correctly configure it...
What would be nice is to have the warning message about "no appenders
configured" should contain a URL to point to a web page with more
information about what this statement means, so that those not familiar with
it (and perhaps log4j) have a point of reference .
cheers,
Paul Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: Platform dependencies problem
Posted by Jacob Kjome <ho...@visi.com>.
At 01:38 PM 5/7/2004 -0600, you wrote:
>Hi,
>
>Currently I have my log output file configured as absolute path in my
>properties file. I have tried to use system variable,
>${TOMCAT_HOME}/myProject/logs/debug.log, but this never seems to work.
You need to make ${TOMCAT_HOME} (or some other variable name set to that
same path) a Java system property. Windows system properties aren't going
to be seen by Log4j unless you provide it specifically as a Java system
property. That will work for both Windows and Unx. You can provide -D
parameters to your startup script or set them dynamically at application
startup.
Jake
>Anyone got this one working on their system, specifically windows and linux?
>I would like to know if there is a tutorial out there listing the steps.
>This is a pain when I when to develop my code in a different platform.
>
>Thanks a million!
>
>-Yan
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-user-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: How Do I Find Out If log4j Has Been Configured?
Posted by WJCarpenter <bi...@carpenter.ORG>.
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.)
--
bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: How Do I Find Out If log4j Has Been Configured?
Posted by Ceki Gülcü <ce...@qos.ch>.
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
Platform dependencies problem
Posted by Yansheng Lin <ya...@silvacom.com>.
Hi,
Currently I have my log output file configured as absolute path in my
properties file. I have tried to use system variable,
${TOMCAT_HOME}/myProject/logs/debug.log, but this never seems to work.
Anyone got this one working on their system, specifically windows and linux?
I would like to know if there is a tutorial out there listing the steps.
This is a pain when I when to develop my code in a different platform.
Thanks a million!
-Yan
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
RE: How Do I Find Out If log4j Has Been Configured?
Posted by WJCarpenter <bi...@carpenter.ORG>.
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.
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?
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.
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.
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".
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.
--
bill@carpenter.ORG (WJCarpenter) PGP 0x91865119
38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org