Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 98737 invoked from network); 18 Jan 2003 03:46:13 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 18 Jan 2003 03:46:13 -0000 Received: (qmail 5479 invoked by uid 97); 18 Jan 2003 03:47:39 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 5405 invoked by uid 97); 18 Jan 2003 03:47:38 -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 5381 invoked by uid 50); 18 Jan 2003 03:47:37 -0000 Date: 18 Jan 2003 03:47:37 -0000 Message-ID: <20030118034737.5380.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: commons-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 15450] - Ability to set levels for loggers X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15450 Ability to set levels for loggers craig.mcclanahan@sun.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WONTFIX ------- Additional Comments From craig.mcclanahan@sun.com 2003-01-18 03:47 ------- The philosophy of commons-logging was, and always has been, to wrap only the actual logging calls -- not the lifecycle or configuration of the underlying logging implementation. That was left to the application itself. In your particular scenario, you could have left the Log4J configuration screens in place, but only allowed them to be accessed when Log4J is available. Likewise, it would be straightforward to build similar screens for JDK 1.4 logging (if available), or any other logging implementation you want to support. Going down the path of adding more and more functionality to commons-logging would lead, ultimately, to writing a complete logging implementation. That would be a waste of time, when perfectly good implementations exist already. Instead, commons-logging should stay narrowly focused on abstracting just the logging calls themselves. -- To unsubscribe, e-mail: For additional commands, e-mail: