tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Louis Tribble <louis.trib...@metamata.com>
Subject Re: [VOTE] On Logging
Date Fri, 23 Jun 2000 20:50:09 GMT
We use a logging component in our own application, so though I'm
not a committer, I'll comment based on experience with that.

> Proposal 1: The default timestamp format to be msec-since-epoch, not
> new Date().toString()
+1

> Proposal 2: Add a "timeStampFormat" property to server.xml/Logger,
> which allows for locale-sensitive string date formatting
+0

Alternative: a logFormat property whose value is a format string:

{component}: {message} ({time})

If going this route, a (non-default) option is to include {thread}
which prints the name of the current thread. This has helped nail
a few multi threading bugs (where something was executing in an
unexpected thread).

> 
> (This may be overkill, so I'd just implement the simple case to start
> with, unless I happen to have just had a cup of coffee)
> 
> > Since you work on logger, is any reason to have the log level in
> > logger and also in the component ?
> >
> > Most components will do a
> >
> > if( debug > internal_level ) log("msg" + arg + arg);

-1 on forcing concatenation to use arguments (see below).

> I think the solution is something like you said Sam Ruby proposed:
> syntax like
> 
>  log("Trying to set {0} to {1}", name, value);
> 
> That way no string formatting would take place unless the logger's
> level is high enough (after a few method calls, which isn't that big a
> performance deal in case it's below threshold).
> 

+1000

Many toString() implementations are glacially slow, and
that should be ok. You can easily use java.text.MessageFormat to
implement this, but that's not very robust with respect to null or 
insufficient arguments and probably is higher in overhead than the 
logger needs. It's better to roll your own. If doing so, a useful 
enhancement is when an argument is an array, print the elements 
instead of the toString...

> Proposal 3: Remove concept of debug level from each component; just
> make each logger sensitive to the debug level, and only print messages
> with a low enough level.

+1

> 
> Proposal 4: Set the interface of LogHelper (and probably Logger) to:
> 
>  public void log(int level, String message, Object[] params, Throwable exception)
> 
> and many permutations of above, like
> 
>  public void log(String message, Object[] params)
>  public void log(String message, Object param)
>  public void log(String message, Object param1, Object param2, Throwable e)
> 
> where the default level is "Logger.INFORMATION"
> 
> This would allow usage like
>  loghelper.log("My {0} has {1}", "dog", fleas");
> or
>  loghelper.log("The {0} {1} {2} jumped over the {3} {4}",
>                     new Object[] { adjective1, adjective2, noun1, "lazy", noun2));
> 
Defining the level in terms of the type-safe enumeration pattern
seems more robust to me. The enumeration class can still
provide a compareTo function so that the test inside log()
is cheap. It's also been very useful to overload for ints 
and booleans in up to the the first three argument positions 
(depending on your stomach for a lot of overloadings).

Regards,
Louis

P.S. If desired, I can supply the code for configuring 
and formatting as I described above, in a form that 
should be easy to drop in.
-- 

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Louis Tribble                                         louis@metamata.com
Metamata, Inc.                                   http://www.metamata.com
Tools for serious Java developers.                       +1 510 796 0915
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>

Mime
View raw message