Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 88016 invoked from network); 10 Feb 2003 20:34:35 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 10 Feb 2003 20:34:35 -0000 Received: (qmail 8776 invoked by uid 97); 10 Feb 2003 20:36:08 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@nagoya.betaversion.org Received: (qmail 8769 invoked from network); 10 Feb 2003 20:36:08 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 10 Feb 2003 20:36:08 -0000 Received: (qmail 87690 invoked by uid 500); 10 Feb 2003 20:34:32 -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 87679 invoked from network); 10 Feb 2003 20:34:31 -0000 Received: from pcow034o.blueyonder.co.uk (HELO blueyonder.co.uk) (195.188.53.122) by daedalus.apache.org with SMTP; 10 Feb 2003 20:34:31 -0000 Received: from localhost ([80.194.24.21]) by blueyonder.co.uk with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Feb 2003 20:36:17 +0000 Date: Mon, 10 Feb 2003 20:35:10 +0000 Subject: Re: [logging] To depend or not to depend? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v482) From: robert burrell donkin To: "Jakarta Commons Developers List" Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <265FB7A2-3D37-11D7-A3B0-003065DC754C@blueyonder.co.uk> X-Mailer: Apple Mail (2.482) 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 Saturday, February 8, 2003, at 01:21 AM, Leo Simons wrote: > Personal preferences 'n stuff > ----------------------------- > I like a library that doesn't use anything with a 'static' keyword > attached to any of its methods that actually do much. It just makes life > easier in the classloader-hell world we have in java. I would like the > commons libraries to use a similar setup to Digester's setLogger() as > much as possible. > > Possible solution/workaround > ---------------------------- > Now, I saw someone suggest this problem is avoidable, ie by putting in > place an alternative implementation for commons-logging which intercepts > stuff like getInstance(), perhaps always providing a NoOpLog. This sounds > like a workable, easily implementable idea, even if it feels 'hacky'. > IIUC what would happen is we put in place > > commons-logging-noop.jar (commons-stub.jar) > commons-cli.jar > commons-lang.jar > commons-(...).jar > > and never again get anxious about > > commons-logging > > Sounds like a plan, and probably a rather common need for many projects, > not just avalon. i started wondering whether something like this would be possible without actually having to create a dummy implementation. when the current code fails to create a LogFactoryImpl instance, it throws a runtime exception. this could be changed so that the exception is caught and a factory which return no-op logs returned instead. then if a minimal jar (excluding all the implementations) only was present, you'd get the no-op behaviour required. - robert --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org