directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ceki Gülcü <>
Subject Re: [ApacheDS] General things to do for 1.0
Date Wed, 11 Jan 2006 15:54:26 GMT
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 

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

> > >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.


> > 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 

>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:

View raw message