Hi Ceki !
Thanks for the comments. Here are some comments on your comments ;)
> 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)
- is it possible to get rid of commons-logging? We are using Spring
that need it.
> >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 ;)
> >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.
> 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.
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" ;)
Thanks a lot for those advises, I will change points that are obvious
right now.
--Emmanuel Lécharny
