tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@eng.sun.com>
Subject Re: [VOTE] On Logging
Date Fri, 23 Jun 2000 21:00:33 GMT
> Vote please:
>
> Proposal 1: The default timestamp format to be msec-since-epoch, not
> new Date().toString()

+1 ( or +2 if possible )
Or at least make this optional if anyone wants it.
-1 on having the default as Date.toString


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

-0.
I don't think it's needed, plus no server does that ( AFAIK ). Plus it's too
much work.


> I agree that each component having its own log level is confusing, but
> that it may be useful when trying to debug a particular component (as
> you mentioned).  However, that can be worked around by just setting
> the global level high, then grepping the log for the name of the
> component you're interested in.  With LogHelper each message is tagged
> with the name of its source, so this is easy.  So I don't think the
> extra complexity of each component having its own level is warranted.

I don't think it's a good idea - many components have a lot of output.

I'm using printf as debugger a lot - and at least for me it's very important
to debug individual components and be able to set the level per component.

Please don't remove the individual debug level !!!


> Another problem is that the concept of "level" seems to have different
> semantics in different parts of the program; at some points people
> treat it as an int (if (level > 9)), at others, like an enum
> (Logger.INFORMATION).

The 3-4 levels are not enough - each component has different levels of
verbosity, and most times they are not just DEBUG, INFORMATION,
WARNING, etc.
There are many distinct levels of DEBUG messages.


> 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).
>
> Vote please:
>
> 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 . It's the feature I use the most for debugging, at least I would
be very affected by such a change.
+1 on removing the global level/



> 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));
>
> The key here is to make it easy for programmers to insert log
> messages.

+1

One sugestion: maybe replace the first parameter with:
log( int component, int messageType, ... );

String operations are expensive ( for example some logs will have to
be internationalized, and then you'll have a Hashtable lookup).

Plus, you'll be able to plug in your own message format ( as a resource
bundle or a Messages implementation ) - including XML
"<component attrib='{0}' ../>".

> Along those lines, are there any strong feelings for or against
> standardizing server log messages as English?  The arguments for this
> are, it keeps strings right in the code, so it's easier to program and
> maintain, and since no end-users will see the logs, just programmers,
> then the need for localization is less compelling.  Also, it would
> allow standard log parsing tools or scripts to work in any country
> without needing to be localized.

Debug messages in English, errors and whatever goes to client
internationalized.

It's too painfull to translate debug messages, and will slow down
everything ( and we want to have as many traces as possible, that's
_very_ important for fixing bugs - if we make this difficult people
will not do it).


> > >   Does anyone actually use non-custom logs?
>
> Anyone? Meaning the <tc_log>message</tc_log> format...

I don't think so - very few people liked the idea ( or the implementation )
anyway.

If we add the log( type, param, parm ) - it will be trivial to implement it
in a modular way.

Costin


Mime
View raw message