Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 94518 invoked from network); 20 Feb 2006 00:57:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 20 Feb 2006 00:57:12 -0000 Received: (qmail 81676 invoked by uid 500); 20 Feb 2006 00:57:09 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 81652 invoked by uid 500); 20 Feb 2006 00:57:09 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 81641 invoked by uid 99); 20 Feb 2006 00:57:09 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 19 Feb 2006 16:57:09 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of remy.maucherat@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; Sun, 19 Feb 2006 16:57:07 -0800 Received: by wproxy.gmail.com with SMTP id i6so517584wra for ; Sun, 19 Feb 2006 16:56:47 -0800 (PST) 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:content-transfer-encoding:content-disposition:references; b=J3p2jaxei1AgVMJGGaOqEOquSSSQ+OzkhZQvFBGvBjLMrCk7f3xvc51oYeC6cRaWNou7tjzp/BuZ366uZJBi10/F2aM5B7D8ZNEQFnmvM63yA736dF9rOTi+r5baDMezl11slTmEtJfZB0jN+ddKtioaV1b1AVlG19ESdprbyV4= Received: by 10.54.151.4 with SMTP id y4mr3310215wrd; Sun, 19 Feb 2006 16:56:46 -0800 (PST) Received: by 10.54.104.7 with HTTP; Sun, 19 Feb 2006 16:56:46 -0800 (PST) Message-ID: <6d959d480602191656g6811172cvb16ed784f63cef7a@mail.gmail.com> Date: Mon, 20 Feb 2006 01:56:46 +0100 From: "Remy Maucherat" To: "Jakarta Commons Developers List" Subject: Re: [logging] JCL2.0 design - Architecture In-Reply-To: <1140391767.3813.148.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1140390127.3813.119.camel@localhost.localdomain> <1140391767.3813.148.camel@localhost.localdomain> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I am not very enthusiastic (from the container perspective). Let's see: - Static discovery may look nice to some, but given the most likely class overloading rules, it means the whole container and its applications would use a single logging framework (which is ok in many cases, though). So IMO you need to keep a working dynamic discovery. - Please continue providing support for using the TCCL (as the TCCL - or similar - is used in most JNDI impls, doing otherwise is a bit redudant as far as I am concerned, and JNDI access is most likely slower). - If you're changing the API, I think you should consider using java.util.logging as the facade API to replace the commons-logging 1.0 API. While the API exposed might be a bit sub optimal, this would be the most "standard" way from users' perspective. See JULI in Tomcat, and www.x4juli.org for java.util.logging "implementations" (providers may be more accurate), but both are done using the full-logging-implementation way, so maybe not very good examples, as you would want to only develop facades. -- xxxxxxxxxxxxxxxxxxxxxxxxx R=E9my Maucherat Developer & Consultant JBoss Group (Europe) S=E0RL xxxxxxxxxxxxxxxxxxxxxxxxx --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org