Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 2917 invoked from network); 14 Feb 2002 21:52:11 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 14 Feb 2002 21:52:11 -0000 Received: (qmail 1725 invoked by uid 97); 14 Feb 2002 21:52:14 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 1687 invoked by uid 97); 14 Feb 2002 21:52:13 -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 1676 invoked from network); 14 Feb 2002 21:52:13 -0000 Date: Thu, 14 Feb 2002 13:52:06 -0800 (PST) From: "Craig R. McClanahan" To: Jakarta Commons Developers List Subject: Re: cvs commit: jakarta-commons/logging/src/java/org/apache/commons/logging LogFactory.java In-Reply-To: <20020214210919.40080.qmail@icarus.apache.org> Message-ID: <20020214134900.P45149-100000@icarus.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N 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 14 Feb 2002 costin@apache.org wrote: > Date: 14 Feb 2002 21:09:19 -0000 > From: costin@apache.org > Reply-To: Jakarta Commons Developers List > To: jakarta-commons-cvs@apache.org > Subject: cvs commit: > jakarta-commons/logging/src/java/org/apache/commons/logging > LogFactory.java > > costin 02/02/14 13:09:19 > > Modified: logging/src/java/org/apache/commons/logging LogFactory.java > Log: > Add the standard ( ? ) JDK1.3 'service provider' mechanism. It's usually better > to use the standards ( if it makes sense ), and that's something that > works well enough ( crimson, xerces, xalan, saxon, etc). > > Changed the code that deals with 'properties'-based setup. The propertis > will be set on the factory regardless of the discovery mechanism. > This may be arguable, but at least it's symetrical and permits the > application to pass the information to the logger implementation in > all cases. Given that the properties are read by the class loader, > each application can have it's own settings (even if > the admin sets a JVM-wide default by using a system property ). > +1 on these changes. Craig -- To unsubscribe, e-mail: For additional commands, e-mail: