At 03:29 PM 1/11/2006, you wrote:
Hi Ceki !
Thanks for the comments. Here are some comments on your comments ;)
Thanks for your comments on my comments. Here are my comments on your
comments on my comments. I am looking forward to your comments on my
comments on your comments on my comments. This kind of geek humor may
quickly get tiresome, but hey, you started first! :-)
> You may want to consider slf4j instead of nlog4j.
We can switch easily. I wanted to avoid the code to share two jars
(some projects used slf4j and others Nlog4j. Some are still using
commons-logging ;( ). That leads to some more questions :
- when will 1.0 of slf4j be available? (I saw that 1.0-RC5 is out, so
I bet taht it will be soon)
Hopefully, if no one reports a new bug on RC5, then 1.0final should be
released at the end of the month.
- is it possible to get rid of commons-logging? We are using Spring
that need it.
I am pleased to say that the answer is yes. You can replace
commons-logging.jar with jcl104-over-slf4j.jar. The latter offers exactly
the same API as commons-logging but actually relies on SLF4J to select the
final logging system. You can thus replace commons-logging (a.k.a JCL) with
a more robust solution without touching existing code. So, you can do:
spring -> JCL -> SLF4J -> log4j
The JCL->SLF4J step is provided by jcl104-over-slf4j.jar. The only downside
with jcl104-over-slf4j.jar is that it obfuscates caller information (but
only for the code going through JCL.) In other words, if the chosen logging
system was log4j, then the conversion specifiers such as %L and %F would
report incorrect caller information for log statements generated by
invoking the JCL API. This is a nuisance but usually an acceptable one. The
log statements generated by invoking SLF4J will show correct caller
information.
jcl104-over-slf4j.jar comes in handy when the application environment has
decided on the SLF4J API but other third party libraries relying on
commons-logging still need to be supported. (This is similar to the case
you describe.)
In the case where the larger application environment uses JCL, a smaller
application part can still use SLF4J without disrupting the larger
application. Indeed, another jar file, namely, slf4j-jcl.jar delegates the
choice of the logging system to JCL so that the dependency on SLF4J by some
smaller component becomes transparent to the larger whole.
This is also covered at http://www.slf4j.org/manual.html#gradual
> >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.
The idea here is to allow the "user" or the maintainer to set some
specific classes to DEBUG if needed. If you don't know which classes
are logged, that can be difficult. I was thinking of a task (ant or
maven) that grep for LoggerFactory.getLogger( <class name>.class ) in
the sources to gather those infos. So it can be automated. Don't know
if it's the idea of the century ;)
Assuming 80% percent of the logs are generated by 2% of the classes (which
may or may not be true in the case of ADS), it may be sufficient to
document just a few particularly verbose classes.
> >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.
Sure. The configuration file will be put aside, but we may want to set
some basic instructions into the main configuration file, at least the
name of the log configuration file !. I was thinking of the way Tomcat
set traces. We can then tell ADS to run MINA in DEBUG mode, and only
MINA. But it will not be very low grained logs instructions.
Sounds reasonable.
> Note that the if(log.isXYZEnabled() blocks are superfluous with
> parameterized printing methods available in the SLF4J API.
I've to look at this cool feature. Thanks for pointing that !
> >8) Add some cool appender like DatedFileAppender in the default
configuration
>
> If DailyRollingFileAppender is probably the best choice.
The problem with DailyRollingFileAppender is that if you don't have
any log just after midnight, then the log file could be rotated really
late. I've experienced this problem in many applications in
production, where logs where moved from production servers to backup
servers at 3 AM, when their activity is low and when the logs are
supposed to be rotated and dated. Sometime, it's not the case, so we
can't have the previous day logs, which can be harmfull.
Acknowledged.
> 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.
Well, the point is that when you have formated messages like :
"Connection Failure to server {0} from server {1}". You then need to
use regexp, which is very costly. What you generally need is first to
know which kind of connection failure you have. Here, the message is
totally stupid, because it don't give syou any valuable information
about this. I would have like to found something like:
"Ldap Connection Failure to server {0} from server {1}", but, you know
that developpers are lazzy, and you often get something like :
"Cnx failure". And I also think that error messages deserve to be put
in a ressource file, and used through a constant like
LDAP_CONNECTION_FAILUE which could be a integer, for instance.
OK, but doesn't asking developers to properly number their logs assume that
developers will be disciplined? If lazy (or undisciplined) developers were
the justification for numbered logs, isn't there a contradiction in the
form of cyclical logic? It may be easier to educate developers so that they
write non-cryptic log messages instead of requiring them to uniquely number
them.
So it's not only a matter of speed, but a mix between different needs.
We will have to state about it, because I may be a little bit too
conservative in this approach. As englishmen say : "This is not
because we disagree that I'm right" ;)
Englishmen know how to debate.
Thanks a lot for those advises, I will change points that are obvious
right now.
My pleasure.
--Emmanuel Lécharny
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
