Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 46433 invoked from network); 5 Apr 2002 15:04:07 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 5 Apr 2002 15:04:07 -0000 Received: (qmail 18147 invoked by uid 97); 5 Apr 2002 15:04:07 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 18131 invoked by uid 97); 5 Apr 2002 15:04:07 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: 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 18120 invoked from network); 5 Apr 2002 15:04:06 -0000 Date: Fri, 05 Apr 2002 10:04:06 -0500 From: "Geir Magnusson Jr." Subject: Re: [logging] Need interface... VOTE In-reply-to: To: Jakarta Commons Developers List Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT User-Agent: Microsoft-Entourage/10.0.0.1309 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On 4/5/02 9:47 AM, "costinm@covalent.net" wrote: > On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote: > >> All I want is a base 'commons component' with two interfaces (ok maybe more >> than two - three) >> >> o.a.c.genericlog.Log >> o.a.c.genericlog.LogUser >> o.a.c.genericlog.LogFactory > > You already have 2 of them ( Log and LogFactory). In o.a.c.l with some implicit assumptions (which I am trying to dodge...) > The question about > LogUser is use case - most people don't think this is a common-enough use > - pushing or replacing the logger in a component, when it's so easy to > get it and the configuration is done 'behind the scene' > Uh huh. :) Maybe it's not a "commons enough" use case, but the avalon people certainly are in love with it... > What about > o.a.c.logmanager.LogUser - define the interface to be implemented by > components who want to support setLog() > o.a.c.logmanager.LogManager - define interface for setting the > properties if a Log, like level, appenders - the minimal stuff that is > common to all loggers. > (maybe few others ). That would be cool - but setLog() sets the factory, so you can recover the pull model as well w/o giving anything up. > I would be +0 on this ( I think the push and management APIs should be > part of c-l itself, not a separate package ). I do to, but it seems to me that the underlying implementation assumptions of o.a.c.l are somewhat at odds with the notion of implementation-free generic interface... So that's why I thought a sep package o.a.c.gl was the way to go - light, and totally compatible with o.a.c.l -- Geir Magnusson Jr. geirm@optonline.net System and Software Consulting POC lives! -- To unsubscribe, e-mail: For additional commands, e-mail: