Hello Emmanuel,
Here are a few short comments.
At 09:38 PM 1/10/2006, Emmanuel Lecharny wrote:
Hi,
here are some thougjt about Logs and what need to be done, what could be
done, and what I've in mind but that need agreement :
1) Remove System.out from the base code (except for tests and may be for
clients). We have 129 of them, but only 24 are found in base code
2) We must switch to NLog4j 1.2.21 for all the projects. Some of them are
using slf4j or commons-log, r nlog4j-1.2.17
You may want to consider slf4j instead of nlog4j. The slf4j API will allow
the end user to switch between log systems by dropping in the appropriate
jar file on the class path at deployment time. Moreover, slf4j will allow
you to effortlessly use the successor of log4j when such a system becomes
available.
3) Check that every class that need a logger does it correctly.
This type of verification is always a good idea.
4) Gather in a property file *all* the loggers
This may results in a high maintenance effort. It may be better to check
the log output and suppress those log messages which are deemed too noisy.
5) See if we can add some configuration is server.xml file to allow debug mode
This bears a directly relationship to the previous point (4). You would
want to place the suppression instructions in a configuration file.
6) Check that when log.debug is used, we have a if (log.isDebugEnabled())
Note that the if(log.isXYZEnabled() blocks are superfluous with
parameterized printing methods available in the SLF4J API.
7) check if we can add a mechanism (JMX?) to change the log level dynamically
8) Add some cool appender like DatedFileAppender in the default configuration
If DailyRollingFileAppender is probably the best choice.
9) Test the chainsawV2 tool
10) Try to use a MessageFormat to store logs, and the use a
RessourceBundle file for error messages (I18n in mind) (beware of
synchronization pb !)
11) Add a number for each message. For instance :
* project org.apache.asn1 : 10000
* project org.apache.directory.kerberos.common : 20000
etc.
and
* FATAL : 0 -> 1999
* ERROR : 2000 -> 3999
* WARN : 4000 -> 5999
* INFO : 6000 -> 7999
* DEBUG : 8000 -> 9999
Si if we have a message [24364], then we know that it's a project
org.apache.directory.kerberos.common message, and that's it's a WARN
level, and that it's number is 364.
It will be totally useless for a human-being, but it will be very
interesting if we need to grep for some specific errors in a huge log
file. (I remember, years ago, having to chew a 2.7 Gbytes log file with
regexp to get the valuable infos out of it. Took 8 hours to get them, on a
very expensive server which has enough CPU and memory to do it during
night. Of course, I got many errors like "Connection failure", which were
totally useless, as we used this message for DB connection failures, Ldap
connection failures, EJB connection failures - wasn't my code, btw - ;)
You might want to consider the fact that most string search algorithms
perform (linearly) better with longer search strings. So, searching for
"ABCDEFGHIJKLMNOP" (16 letters) will be about 16 times faster than
searching for just "A". If you know the string to search for, which
presumably will be longer than 5 letters (the length of the code), then
searching for plain text should be faster. So, if adding a code for each
message for speeding up searches is probably not a good idea.
wdyt ?
Just my 2c.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
