From dev-return-8347-apmail-directory-dev-archive=directory.apache.org@directory.apache.org Wed Oct 12 00:25:17 2005 Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 8034 invoked from network); 12 Oct 2005 00:25:17 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 12 Oct 2005 00:25:17 -0000 Received: (qmail 72175 invoked by uid 500); 12 Oct 2005 00:25:16 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 71983 invoked by uid 500); 12 Oct 2005 00:25:15 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 71972 invoked by uid 99); 12 Oct 2005 00:25:15 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Oct 2005 17:25:15 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of trustin@gmail.com designates 64.233.184.200 as permitted sender) Received: from [64.233.184.200] (HELO wproxy.gmail.com) (64.233.184.200) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 11 Oct 2005 17:25:15 -0700 Received: by wproxy.gmail.com with SMTP id 71so433938wri for ; Tue, 11 Oct 2005 17:24:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=mRCnnrCMQuE2lfz2urlNhQKpCJFBlY1cuVPO9CGMHqFpIxgA3mABgfYipKgWxBM3WyY/zGuC5XtHNd1PqbkP/unW1xt5797C35bld3c1s2JOshhWkdzI8elj6L1jNglLG4qYAK54GMmqku0LxXaVMYzIGmlq2b4KiAbx89sndc0= Received: by 10.54.120.20 with SMTP id s20mr3781755wrc; Tue, 11 Oct 2005 17:24:52 -0700 (PDT) Received: by 10.54.71.11 with HTTP; Tue, 11 Oct 2005 17:24:51 -0700 (PDT) Message-ID: <768dcb2e0510111724q69b89f1dk@mail.gmail.com> Date: Wed, 12 Oct 2005 09:24:52 +0900 From: Trustin Lee To: Apache Directory Developers List Subject: Re: upgrading to nlog4j.1.2.17 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_10195_11854610.1129076692000" References: <200510111510.26004.niclas@hedhman.org> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_10195_11854610.1129076692000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 2005/10/12, Noel J. Bergman : > > Niclas Hedhman wrote: > > > Once you understand Paul Hammant's argument of "No Logging", > > things get very clear indeed. This monitor pattern is overengineering IMHO. Why should I add extra method= s whenever I write debug log messages and provide a bridge for known logging frameworks? And we can say using monitors is implementing AOP almost by hand. However, as Paul says: "the main point is the proper way to abstract loggin= g > type and destination is to hide all logging implementation behind an > interface." I agree. And at this point, since we have a standard, perhaps > it is time to follow Tomcat's lead: ditch all other logging APIs, and use > the standard. If the standard needs change, that can happen via the JCP. > Log4J and others would still have their place as implementations of the > standard, but as APIs they would go away. Standard is good, but is java.util.logging de-facto standard really? There are a lot of projects that use other logging frameworks, and that's why projects like MX4J provides their own layer of logging which is not that pretty. Commons-logging was a nice try, but ppl doesn't seem to like it due to its hard traceability though I think it is OK because we know what problem is. It would be really great if the ASF members and committers come to a mutual agreement on which logging framework we will use. Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ ------=_Part_10195_11854610.1129076692000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 2005/10/12, Noel J. Bergman <noel@de= vtech.com>:
Niclas Hedhman wrote:

> Once you understand Paul Hammant's argume= nt of "No Logging",
> things get very clear indeed.

This monitor pattern is overengineering IMHO.  Why shoul= d I add extra methods whenever I write debug log messages and provide a bri= dge for known logging frameworks?  And we can say using monitors is im= plementing AOP almost by hand.

How= ever, as Paul says: "the main point is the proper way to abstract logg= ing
type and destination is to hide all logging implementation behind aninterface."  I agree.  And at this point, since w= e have a standard, perhaps
it is time to follow Tomcat's lead: ditch all= other logging APIs, and use
the standard.  If the standard needs change, that can happen = via the JCP.
Log4J and others would still have their place as implementa= tions of the
standard, but as APIs they would go away.
=
Standard is good, but is=20 java.util.logging de-facto standard really?  There are a lot of projec= ts that use other logging frameworks, and that's why projects like MX4J pro= vides their own layer of logging which is not that pretty.  Commons-lo= gging was a nice try, but ppl doesn't seem to like it due to its hard trace= ability though I think it is OK because we know what problem is.

It would be really great if the ASF members and committ= ers come to a mutual agreement on which logging framework we will use.
<= br>Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/ ------=_Part_10195_11854610.1129076692000--