From dev-return-69989-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Wed Jan 05 23:24:21 2005 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 91687 invoked from network); 5 Jan 2005 23:24:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 5 Jan 2005 23:24:20 -0000 Received: (qmail 63662 invoked by uid 500); 5 Jan 2005 23:24:17 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 63619 invoked by uid 500); 5 Jan 2005 23:24:16 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 63604 invoked by uid 99); 5 Jan 2005 23:24:16 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from dd2020.kasserver.com (HELO dd2020.kasserver.com) (81.209.148.130) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 05 Jan 2005 15:24:13 -0800 Received: from [192.168.1.2] (pD9E9D709.dip0.t-ipconnect.de [217.233.215.9]) by dd2020.kasserver.com (Postfix) with ESMTP id 58263196A90 for ; Thu, 6 Jan 2005 00:24:10 +0100 (CET) Message-ID: <41DC775B.9030308@apache.org> Date: Thu, 06 Jan 2005 00:25:15 +0100 From: Torsten Curdt User-Agent: Mozilla Thunderbird 0.9 (X11/20041203) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [RT] Logging in 2.2 References: <41DBD357.1000802@apache.org> <41DC696C.2070209@apache.org> In-Reply-To: <41DC696C.2070209@apache.org> X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N > We are not using logkit: we are using Avalon Logger, and the default > configuration shipped with Cocoon use the LogKit implementation of > Avalon Logger (you say the same below). true >> Why do we really need logkit? I honestly don't know. > > > Because it's not bloated? well ...I think keeping an abstraction layer is not a bad idea. But the question which one to use... so this would be more about commons-logging vs avalon logging vs UGLI. As for the abstraction layers I cannot really say which one of those is more bloated than the other. But since we a lot of components are already relying on commons-logging the question is whether is makes sense to get rid of another dependency. For 2.2 we have jdk 1.4 as a requirement so we *could* ship without *any* logging implementation ...and everyone could just plug in what ever he wants. That's one thing... > Your proposal omits an important point: why do we use IoC loggers? The > classical way of getting a Category in log4j is to use : > private static Logger logger = Logger.getLogger(Blah.class); > > That leads to a topological organization of logger hierarchies (it's the > class name) whereas IoC-style logger the way we do it using the "logger" > attribute allows for a functional organization of hierarchies, as we can > group logs of related components into a single category whatever their > class name, thus easing filtering. ...if you chose to get the logger from the class. Which you don't have to do. But you are right. I probably the most important question is: do we need or do we want IoC style logging. > - I certainly don't want to start again something similar to the > migration from Loggable (logkit-specific) to LogEnabled (not talking > also of Composable to Serviceable). I hear you ...such big changes *are* a PITA. And we need see whether it's worth it. For me I see UGLI being ruled out until someone can provide a good reason to switch. As already being pointed out - we still need the isBlaEnabled stuff with it. No matter whether in source code or added at build time. So I see it like that: commons-logging o one dependencies less o not IoC o potential classloader issues(?) avalon logging o nothing to change o IoC ...I am not a friend of IoC-logging anymore. But whether that's worth the change? Don't know... cheers -- Torsten