commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [logging] To depend or not to depend?
Date Mon, 10 Feb 2003 20:35:10 GMT
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
>     <dependency><id>commons-logging</id></dependency>
> 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:
For additional commands, e-mail:

View raw message