You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Ole Ersoy <ol...@gmail.com> on 2008/06/22 23:20:00 UTC
[Logging] Facility Specific Properties
Hi,
I would really appreciate it if someone could elaborate on the case for these logging properties:
############################################################
# Facility specific properties.
# Provides extra control for each logger.
############################################################
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level = INFO
org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers = \
3manager.org.apache.juli.FileHandler
For example what additional logging capabilities does the above give in the context of these properties:
3manager.org.apache.juli.FileHandler.level = FINE
3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
3manager.org.apache.juli.FileHandler.prefix = manager.
Also there's this part:
# For example, set the com.xyz.foo logger to only log SEVERE
# messages:
#org.apache.catalina.startup.ContextConfig.level = FINE
#org.apache.catalina.startup.HostConfig.level = FINE
#org.apache.catalina.session.ManagerBase.level = FINE
Should the left side of the equal sign be SEVERE in the above cases (I'll put in a documentation ticket, just making sure)? Seems like these are setting the log level directly on the Logger for the classes listed.
Would it be better to have something like this in the documentation:
# For example, set the org.apache.catalina.session.ManagerBase logger to only log SEVERE
# messages:
#org.apache.catalina.session.ManagerBase.level = SEVERE
?
Also, assuming that the log level is set directly on the logger, does that buy anything? From what I understand the logger has to delegate to a handler eventually, and then the handlers level takes precedence...so is there a point to setting it directly on the Logger?
Thanks,
- Ole
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Logging] Facility Specific Properties
Posted by Ole Ersoy <ol...@gmail.com>.
Quick correction:
> # For example, set the com.xyz.foo logger to only log SEVERE
> # messages:
> #org.apache.catalina.startup.ContextConfig.level = FINE
> #org.apache.catalina.startup.HostConfig.level = FINE
> #org.apache.catalina.session.ManagerBase.level = FINE
>
> Should the left side of the equal sign be SEVERE
That would be the right side - sorry.
- Ole
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Logging] Facility Specific Properties
Posted by Ole Ersoy <ol...@gmail.com>.
Super - Thanks for the elaboration!
- Ole
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ole,
>
> Ole Ersoy wrote:
> | I hope the mappings are all inclusive from java.util.logging's
> | perspective so that if I set the a level to INFO I get info, plus
> | possibly some other level's that are greater than INFO? In other words
> | something that should be mapped to info, does not end up corresponding
> | to say FINE, and is thus left out?
>
> Yes. The level chosen really means "this level and above" -- it's not
> specifically that level and that level only.
>
> | I would think that it's always appropriate to use commons logging within
> | Tomcat and anything (java.util.logging, log4j, or commons-logging) goes
> | for webapps?
>
> Tomcat uses commons-logging internally and then your choice of "real"
> loggers to actually do the job. In your webapps, you can use (that is,
> write into your own code) commons-logging or log4j or Java's logging or
> whatever you want.
>
> If you use commons-logging and the same logger across all web
> applications, you get the benefit of all logging for the entire server
> (internals + webapps) being set up in one place.
>
> If you separate them (which I recommend), you get the benefit of logging
> configuration for a particular application being bundled with that
> application (which sort of follows the "self-contained" principle of
> applications.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkhgPRcACgkQ9CaO5/Lv0PBtSwCfQl+hau6bgp+XSgI35PexhHBm
> SJAAn2Ku7yDaCgflfP3Zsu0F37LEbPBW
> =F9Fn
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [Logging] Facility Specific Properties
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Ole Ersoy [mailto:ole.ersoy@gmail.com]
> Subject: Re: [Logging] Facility Specific Properties
>
> Good catch! I just checked the 5.5 documentation and it's
> the same as Tomcat 6.
Not quite. The procedure for replacing java.util.logging with log4j is a bit different.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Logging] Facility Specific Properties
Posted by Ole Ersoy <ol...@gmail.com>.
> | From what I understand Tomcat 6 logging has been overhauled and the
> | java.util.logging implementation was replaced with JULI, which
> | understands how to load per web app configuration files and make the
> | corresponding configuration available via the LogManager to the web app.
>
> I think that happened in 5.5, but I haven't read the code. :(
Good catch! I just checked the 5.5 documentation and it's the same as Tomcat 6.
>
>
> Yes, log4j Appenders ~= Java logging's Handlers
> The name "logger" in both packages are roughly equivalent.
Cool - Thanks for confirming,
- Ole
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Logging] Facility Specific Properties
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ole,
Ole Ersoy wrote:
| From what I understand Tomcat 6 logging has been overhauled and the
| java.util.logging implementation was replaced with JULI, which
| understands how to load per web app configuration files and make the
| corresponding configuration available via the LogManager to the web app.
I think that happened in 5.5, but I haven't read the code. :(
|> to overcome these limitations as well as the ability to configure in
|> Appenders (socket/file etc) replace with Log4j
|> http://logging.apache.org/log4j/1.2/index.html
|
| I think Appenders are the same as Handlers in java.util.logging. So for
| those going with Tomcat 6, JULI provides pretty much the same
| capabilities AFAIK (Socket communication / Handlers / XML Format, etc.).
Yes, log4j Appenders ~= Java logging's Handlers
The name "logger" in both packages are roughly equivalent.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhg9eoACgkQ9CaO5/Lv0PAaVwCfXL7vYA7nILVZ8KM575gqDLhz
65wAnjjJ+HgacDmYOkWsKO8fQHcRT2pl
=Wxxn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Logging] Facility Specific Properties
Posted by Ole Ersoy <ol...@gmail.com>.
Martin wrote:
> Found this helpful
> http://tomcat.apache.org/tomcat-5.5-doc/logging.html
> default logging is commons-logging with known limitation to Engines and
> Hosts
> this limitation of JDK Logging appears to be the genesis of per-web
> application logging as the configuration is per-VM
That sounds great for Tomcat 5.
>From what I understand Tomcat 6 logging has been overhauled and the java.util.logging implementation was replaced with JULI, which understands how to load per web app configuration files and make the corresponding configuration available via the LogManager to the web app.
>
> to overcome these limitations as well as the ability to configure in
> Appenders (socket/file etc) replace with Log4j
> http://logging.apache.org/log4j/1.2/index.html
I think Appenders are the same as Handlers in java.util.logging. So for those going with Tomcat 6, JULI provides pretty much the same capabilities AFAIK (Socket communication / Handlers / XML Format, etc.).
Ole
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Logging] Facility Specific Properties
Posted by Martin <mg...@hotmail.com>.
Found this helpful
http://tomcat.apache.org/tomcat-5.5-doc/logging.html
default logging is commons-logging with known limitation to Engines and
Hosts
this limitation of JDK Logging appears to be the genesis of per-web
application logging as the configuration is per-VM
to overcome these limitations as well as the ability to configure in
Appenders (socket/file etc) replace with Log4j
http://logging.apache.org/log4j/1.2/index.html
FWIW
Martin
----- Original Message -----
From: "Christopher Schultz" <ch...@christopherschultz.net>
To: "Tomcat Users List" <us...@tomcat.apache.org>
Sent: Monday, June 23, 2008 8:17 PM
Subject: Re: [Logging] Facility Specific Properties
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Ole,
>
> Ole Ersoy wrote:
> | I hope the mappings are all inclusive from java.util.logging's
> | perspective so that if I set the a level to INFO I get info, plus
> | possibly some other level's that are greater than INFO? In other words
> | something that should be mapped to info, does not end up corresponding
> | to say FINE, and is thus left out?
>
> Yes. The level chosen really means "this level and above" -- it's not
> specifically that level and that level only.
>
> | I would think that it's always appropriate to use commons logging within
> | Tomcat and anything (java.util.logging, log4j, or commons-logging) goes
> | for webapps?
>
> Tomcat uses commons-logging internally and then your choice of "real"
> loggers to actually do the job. In your webapps, you can use (that is,
> write into your own code) commons-logging or log4j or Java's logging or
> whatever you want.
>
> If you use commons-logging and the same logger across all web
> applications, you get the benefit of all logging for the entire server
> (internals + webapps) being set up in one place.
>
> If you separate them (which I recommend), you get the benefit of logging
> configuration for a particular application being bundled with that
> application (which sort of follows the "self-contained" principle of
> applications.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkhgPRcACgkQ9CaO5/Lv0PBtSwCfQl+hau6bgp+XSgI35PexhHBm
> SJAAn2Ku7yDaCgflfP3Zsu0F37LEbPBW
> =F9Fn
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Logging] Facility Specific Properties
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ole,
Ole Ersoy wrote:
| I hope the mappings are all inclusive from java.util.logging's
| perspective so that if I set the a level to INFO I get info, plus
| possibly some other level's that are greater than INFO? In other words
| something that should be mapped to info, does not end up corresponding
| to say FINE, and is thus left out?
Yes. The level chosen really means "this level and above" -- it's not
specifically that level and that level only.
| I would think that it's always appropriate to use commons logging within
| Tomcat and anything (java.util.logging, log4j, or commons-logging) goes
| for webapps?
Tomcat uses commons-logging internally and then your choice of "real"
loggers to actually do the job. In your webapps, you can use (that is,
write into your own code) commons-logging or log4j or Java's logging or
whatever you want.
If you use commons-logging and the same logger across all web
applications, you get the benefit of all logging for the entire server
(internals + webapps) being set up in one place.
If you separate them (which I recommend), you get the benefit of logging
configuration for a particular application being bundled with that
application (which sort of follows the "self-contained" principle of
applications.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkhgPRcACgkQ9CaO5/Lv0PBtSwCfQl+hau6bgp+XSgI35PexhHBm
SJAAn2Ku7yDaCgflfP3Zsu0F37LEbPBW
=F9Fn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Logging] Facility Specific Properties
Posted by Ole Ersoy <ol...@gmail.com>.
SNIP
> I think one of the confusing things about the current logging environment is the lack of documentation about the mapping between commons-logging and java.util.logging levels and APIs, as implemented by JULI. For example, c-l has six logging levels, whereas as j.u.l has seven; some of the mappings are obvious, some are not. (Yes, I did find the mappings in the DirectJDKLog.java source.)
I hope the mappings are all inclusive from java.util.logging's perspective so that if I set the a level to INFO I get info, plus possibly some other level's that are greater than INFO? In other words something that should be mapped to info, does not end up corresponding to say FINE, and is thus left out?
I also assume that the if developers stick to levels that are common to both java.util.logging and commons-logging, the mapping is straightforward? It's only an issue when attempting to read tomcat log statements or adding new ones right?
>
> In the above snippet from the last two e-mails, Ole uses java.util.logging APIs, and Rainer responds with commons-logging; it's not clear when it's appropriate to use one or the other.
I would think that it's always appropriate to use commons logging within Tomcat and anything (java.util.logging, log4j, or commons-logging) goes for webapps?
Ole
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: [Logging] Facility Specific Properties
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Rainer Jung [mailto:rainer.jung@kippdata.de]
> Subject: Re: [Logging] Facility Specific Properties
>
> > if (myLogger.getLevel() >= Level.WARNING)
> > {
> > myLogger.warn('This is a warning'); }
>
> More precisely:
>
> if (log.isDebugEnabled())
> log.debug(SOMETHING);
I think one of the confusing things about the current logging environment is the lack of documentation about the mapping between commons-logging and java.util.logging levels and APIs, as implemented by JULI. For example, c-l has six logging levels, whereas as j.u.l has seven; some of the mappings are obvious, some are not. (Yes, I did find the mappings in the DirectJDKLog.java source.)
In the above snippet from the last two e-mails, Ole uses java.util.logging APIs, and Rainer responds with commons-logging; it's not clear when it's appropriate to use one or the other.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Logging] Facility Specific Properties
Posted by Ole Ersoy <ol...@gmail.com>.
SNIP
> No it would grab the logger for the context, which will automatically be
> the one for [/mywebapp] and not [/manager]. It can't log to the logger
> of another context. Look at javax.servlet.ServletContext.log().
OOooooh - OK - The gears are starting to turn...maybe. The context logger configuration configures the ServletContext logger. I just erased that from my "To understand" list, since it seems I could just use a pre configured logger per Servlet, but it's good to know.
>
>> make logging calls on it, which assuming the default configuration
>> would end up in the manager prefixed log?
>
> So now you should be able to write an improved version of the logging
> documentation page ;)
Well after having spent a few days reading java logging stuff, commons logging, LogManager stuff, and the Logging for Dummies thread, I'd say that the Tomcat Logging Official documentation hits the nail right on the head. It's about as brief and concise as can be (I'm still going to put in a ticket for a spelling mistake and the context stuff at the end), and gives all the necessary little hooks that someone can branch off on to figure out what's going on. I think the primary cause of panic for Squirl brained individuals, like myself, is that once the branching begins there's a massive (Keep in mind - squirrel brain) amount of information that has to be analyzed and "Felt/Experienced". For instance I spent time playing with java logging to get a reasonable grip after reading through some tutorials and the overview.
So what I'll do is go through the Logging for Dummies thread again and this thread and come with with additions to the logging FAQ on the wiki. I'll do my best to put in an answer + example, but I might need help still.
Thanks again. Hope to have a list compiled asap!
Ole
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Logging] Facility Specific Properties
Posted by Rainer Jung <ra...@kippdata.de>.
Ole Ersoy wrote:
>> 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.
>
> OK - I get it ... hopefully :-). We want to do something like:
>
> if (log.isDebugEnabled())
> {
> //Calculate SOMETHING - Very expensive
> String SOMETHING = SOMETHINGA + SOMETHINGELSE;
> log.debug(SOMETHING);
> }
Close, because of the "if", we would usually simply do
if (log.isDebugEnabled())
{
//Calculate something very expensive
log.debug(SOMETHINGA + SOMETHINGELSE);
}
but it has nearly the same meaning and behaviour as your more explicit
example. The concatenation will be done before actually calling the
debug method.
> So if we are only interested in SEVERE messages, then it seems like it
> would be a good thing to set all of the Tomcat loggers to only log
> severe messages? Is there a simple way to do that? I would think that
> the Tomcat loggers get their log level from a root logger, and that if I
> set the log level on that logger, then it automatically sets it on all
> the other loggers, unless I directly override the logging level as with
> Facility specific properties?
Should be
.level = SEVERE
But even with the default config, Tomcat doesn't log much. So keeping
the default usually is safer, because you actually don't know, how
individual developers decide between using error and severe. So at least
error should be logged to. If there is a sub component, that logs to
much, you should restrict this component and not the whole server.
>> Warnings are not frequent enough to justify the if statement.
>
> So I assume the logic is that most running instances will be interested
> in warnings, hence just skip the if?
Exactly. For log.warn(), developers don't use the isWarnEnabled() idiom.
>> 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.
>
> OK - so /mywebapp could grab the Logger for the /manager context and
No it would grab the logger for the context, which will automatically be
the one for [/mywebapp] and not [/manager]. It can't log to the logger
of another context. Look at javax.servlet.ServletContext.log().
> make logging calls on it, which assuming the default configuration would
> end up in the manager prefixed log?
So now you should be able to write an improved version of the logging
documentation page ;)
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Logging] Facility Specific Properties
Posted by Ole Ersoy <ol...@gmail.com>.
SNIP
> 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.
Thanks for the tip - I will do.
> 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.
OK - I get it ... hopefully :-). We want to do something like:
if (log.isDebugEnabled())
{
//Calculate SOMETHING - Very expensive
String SOMETHING = SOMETHINGA + SOMETHINGELSE;
log.debug(SOMETHING);
}
So if we are only interested in SEVERE messages, then it seems like it would be a good thing to set all of the Tomcat loggers to only log severe messages? Is there a simple way to do that? I would think that the Tomcat loggers get their log level from a root logger, and that if I set the log level on that logger, then it automatically sets it on all the other loggers, unless I directly override the logging level as with Facility specific properties?
> Warnings are not frequent enough to justify the if statement.
So I assume the logic is that most running instances will be interested in warnings, hence just skip the if?
SNIP
>
>> 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.
That's OK. I didn't either :-).
SNIP
>
> 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.
OK - so /mywebapp could grab the Logger for the /manager context and make logging calls on it, which assuming the default configuration would end up in the manager prefixed log?
>
>> 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.
I guess when the day comes for mucking, I'll know it :-).
Thanks again,
- Ole
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Logging] Facility Specific Properties
Posted by Rainer Jung <ra...@kippdata.de>.
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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Logging] Facility Specific Properties
Posted by Ole Ersoy <ol...@gmail.com>.
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?
> 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).
> 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');
}
> 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...?
> 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?
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;
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?
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 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...?
SNIP
Thanks again,
- Ole
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [Logging] Facility Specific Properties
Posted by Rainer Jung <ra...@kippdata.de>.
Ole Ersoy schrieb:
> Hi,
>
> I would really appreciate it if someone could elaborate on the case for
> these logging properties:
>
> ############################################################
> # Facility specific properties.
> # Provides extra control for each logger.
> ############################################################
>
> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level
> = INFO
> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers
> = \
> 3manager.org.apache.juli.FileHandler
>
> For example what additional logging capabilities does the above give in
> the context of these properties:
>
> 3manager.org.apache.juli.FileHandler.level = FINE
> 3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
> 3manager.org.apache.juli.FileHandler.prefix = manager.
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.
The logger here is configured to log only messages at or above level
INFO. They will be output by the handler
3manager.org.apache.juli.FileHandler.
> Also there's this part:
>
> # For example, set the com.xyz.foo logger to only log SEVERE
> # messages:
> #org.apache.catalina.startup.ContextConfig.level = FINE
> #org.apache.catalina.startup.HostConfig.level = FINE
> #org.apache.catalina.session.ManagerBase.level = FINE
>
> Should the left side of the equal sign be SEVERE in the above cases
> (I'll put in a documentation ticket, just making sure)? Seems like
> these are setting the log level directly on the Logger for the classes
> listed.
>
> Would it be better to have something like this in the documentation:
>
> # For example, set the org.apache.catalina.session.ManagerBase logger to
> only log SEVERE
> # messages:
> #org.apache.catalina.session.ManagerBase.level = SEVERE
>
> ?
Yes, would be more logical. The one thing is the comment should fit the
example, on the other hand the given example is one, that people might
actually use.
> Also, assuming that the log level is set directly on the logger, does
> that buy anything? From what I understand the logger has to delegate to
> a handler eventually, and then the handlers level takes precedence...so
> is there a point to setting it directly on the Logger?
Loggers usually check their configured log level before calling the log
method (for FINE/FINEST, resp. DEBUG/TACE). 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. That way, the message doesn't
need to be concatenated as a string when the configured level will not
generate the message. 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).
Another agument, that applies not to juli, but to other log frameworks.
You could send log messages to various handlers, one of them logs
everything above INFO, and another one above ERROR. To do such a thing,
logger log level and handler log level need to be defined independently.
> Thanks,
> - Ole
Regards,
Rainer
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org