Ole Ersoy schrieb:
Rainer Jung wrote:
SNIP
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager]
is the name of a logger, in this case the name of the logger
associated with the context /manager in host localhost in Engine
Catalina.
Most loggers get their names from class names, but context loggers are
special cases.
OK - I think I got that. So I imagine if we grep the tomcat code for
'org.apache.catalina.core.ContainerBase.[Catalina].[localhost]' I'll
find some Logging initialization lines that use that string as the name
of their logger?
Close to that. Since "Catalina" and "localhost" are names of elements in
server.xml, and those names can be changed, this logger name is
generated dynamically. So you won't find it verbosely in the code. Look
at method logName() in ContainerBase.java.
Loggers usually check their configured log level before calling the
log method (for FINE/FINEST, resp. DEBUG/TACE).
CASE A:
OK - So if I'm logging with myLogger and I say myLogger.warn('This is a
warning'); and the logger's level is set to OFF, then the logger will do
minimal work in terms of passing the record to the handler? The reason
I mention it is because the below seems to indicate a different approach
(CASE B).
No, the call log.info(SOMETHING) will need to calculae something, before
it really calls the error method of the logger, which then immediately
might notice, that the configured log level doesn't allow handling an
info message.
Now SOMETHING is quite often not a simple string, but e.g. a localised
message, an exception text, a string concatenation containing some
variable data etc. Java will first calculate SOMETHING, before it jumps
into the logger method. If you have a lot of debug log statements, which
get called during every request, it will have a noticeable impact on
performnce.
The way this is done, is that the developer using the logger checks
with an if statement, if the level is at least the one the message has.
CASE B:
So the tomcat developer has to write something like:
if (myLogger.getLevel() >= Level.WARNING)
{
myLogger.warn('This is a warning'); }
More precisely:
if (log.isDebugEnabled())
log.debug(SOMETHING);
Warnings are not frequent enough to justify the if statement.
That way, the message doesn't need to be concatenated as a string when
the configured level will not generate the message.
I'm just thinking about how I would implement Logger.warn... I think I
would do it like this:
public warn(String message)
{
if (this.level > Level.WARNING)
{
//Now do work to put together a concatenated message
}
//Otherwise this loggers level is not really set to high enough
//so we just return
}
Seems like a plausible way to implement, that way if statements are not
needed outside of the logger. Just want to make sure I'm not missing
something...?
Yes, but there is some work even before we reach the warn method. See above.
This is especially important for debug messages. The developer has no
possibility to check the handlers level in the code, because the
handler as an object is more in the realm of the administrator).
From what I understand the developer could do something like
List<Handler> handlers = myLogger.getHandlers() and check their levels
that way. Hope I don't seem non appreciative of your help. I rarely
use logging myself, so I'm just trying to make sure I understand
everything correctly?
Yes, one could do that, e.g. as part of the isDebugEnabled method, one
could also check the levels of the handlers. Although the API would also
allow the logger to have a more verbose level, than any of the handlers.
If we now suppress the call to the log method, there might be side
effects. I like it the way it is, because it does a clear separatation
of log message producers (the loggers) and consumers (the handlers).
It seems that the only rational for tweaking the level of the loggers in
the logging configuration is to make the logging calls even less
expensive? So for example I could do:
Logger myLogger = LogManager.createLogger(the.name.of.this.class);
myLogger.setLevel = Level.WARNING;
The second line is equivalent to setting the level to WARN via
configuration. One wouldn't put it into code. Even if you know, you will
only produce warnings and more severe messages with this logger, setting
its level to WARN will not change anything.
Because I know that I'll only be doing myLogger.warn('This is really
severe'); type messages. Then if someone wanted to make my logging
calls really efficient they could just set the level of my logger to
SEVERE and since I only make warn calls on myLogger, all the calls will
be as efficient as possible with Java logging...without removing the
logging statement completely that is?
Hmmm, didn't get the point.
Given that the tomcat logging documentation does not go into tweaking
the log levels of all the loggers, I assume that this is something that
would yield very little utility? To be honest I'm still scratching my
Yes, it's needed if someone needs more debugging info. Then he'll tell
you, or you play around with the levels yourself. Not needed during
normal operations.
But: the loggers with the strange names
...Catalina...localhost...mycontext are generated for each context, and
can be used by the webapp developer as part of the servlet API (the
context logger). So the webapp producer might have some documentation,
what kind of log messages he creates at which level.
head on why I'd want to muck around with the Facility Specific
Properties...Maybe the documentation just mentioned them to say "Here -
See - You can Muck!" and then didn't say anything else because theres no
point in mucking...?
Yes, maybe.
Thanks again,
- Ole
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
