incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee" <trus...@gmail.com>
Subject Re: Logging
Date Mon, 24 Apr 2006 09:39:44 GMT
Hi all,

I'm sorry for breaking in this deep discussion. Yes, I had to get in to all
recent discussions but didn't have enough time these days.  I hope I can
participate to most conversation from today.

Here's my opinion on logging:

I disagree with using JDK 1.4 logging API as other people mentioned.

I also don't like monitor pattern from my experience in the Directory
project which adopted the pattern long before and has abandoned it now. It
usually takes serious amount of time only in designing monitors, not the
real implementation.  People start to hesitate to change the software's
behavior or structure because refactoring will impact monitor interfaces
seriously.  IMHO, monitor pattern is a poor choice than JDK 1.4 logging API
from the view point of rapid development and continuous refactoring.

My suggestion is to use SLF4J.  The Apache Directory project team is using
SLF4J and we're very satisfied with it.  It is very similar to
commons-logging, but it doesn't have any class loader issues commons logging
is suffering from.  Moreover, Ceki's support was very responsive.

Another option would be defining our own simplistic logger interface like
MX4J team did.  This is OK, but filtering log message in a fine-grained
manner will make the logger interface as complex as other logging frameworks
so the merit of the thin home-grown interface is gone.  That's why MX4J's
messages are not be able to be filtered by package or class; it uses only
one log category.  But this information might be outdated.  Please let me
know if I'm wrong.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message