commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [CLI] new design possibly?
Date Thu, 06 Feb 2003 14:14:20 GMT

James Strachan wrote, On 06/02/2003 12.32:
> From: "Nicola Ken Barozzi" <>
>>Henri Yandell wrote, On 06/02/2003 11.18:
>>>On Thu, 6 Feb 2003, Henri Yandell wrote:
>>>>On Thu, 6 Feb 2003, Nicola Ken Barozzi wrote:
>>>>>One point that we would like to see is that commons logging is never a
>>>>>*hard* dependency. That means that if commons logging is not in the
>>>>>classpath, the package should be able to work correctly, even if with
>>>>>logging disabled.
>>>>Please justify this. Is it solely because you have people who refuse to
> go
>>>>near commons-logging, or is there a technical reason?
>>>I'm just funked. Ignore this.
>>Naa, you are right, I have to justify it.
>>The fact is that Commons Logging does not advocate IOC, Inversion of
>>Control, that is so dear to us.
> I know this is probably gonna end up a pointless religious debate or
> flamefest but I couldn't resist...

Probably it will end up in explaining misconceptions ;-P

> I see no reason why someone can't use Commons Logging in an IOC pattern if
> thats what they want to do. It boils down to a framework/religious issue
> rather than anything fundamentally wrong with commons logging.
> e.g.
> import org.apache.commons.logging.Log;
> public class SomeService {
>     // container sets the logger to be used using IOC
>     public void setLog(Log log);
> }

Is that what packages using Commons Logging do?
Every single package in Commons that uses CL uses the static accessor.

What you say is correct, and I would like it to be a possible method to 
enable logging to the component.

> Whether there's an explicit LogEnabled marker interface or bean
> introspection is used (I prefer the latter) makes little difference - its
> still IOC isn't it? Unless IOC is only IOC with explicit marker interfaces?

It's clear to me that you haven't looked at LogEnabled. It's not a 
marker interface.

  * Components that need to log can implement this interface to
  * be provided Loggers.
  * @author Avalon Development Team
public interface LogEnabled
      * Provide component with a logger.
      * @param logger the logger. Must not be <code>null</code>.
     void enableLogging( Logger logger );

> Comparing commons logger and the logkit in Avalon Framework (and ignoring
> their history for now) - they now look practically identical apart from the
> LogEnabled interface (which isn't really needed anyway though I'm sure if it
> was essential to Avalon users there wouldn't be much resistence to adding
> something like this to commons-logging).

Let me try to explain. LogEnabled is *not* part of Logkit. LogEnabled is 
part of the Avalon Framework. The avalon framework can log to multiple 

Logkit is a logging implementation, that had it's reason to be at a 
point in history. Now it makes less sense, and we are discussing about 
what to do. But that's another thing.

Back on track: yes, it can make sense to evaluate Commons Logging as a 
facade for Loggers, but it's a major break in our main code contracts.
We are discussing about Avalon 5, and Configuration and Logging are a 
major part of that discussion. You are invited  :-)

> Indeed there's nothing to stop someone using logkit in Avalon Framework in a
> non-IOC way.
> public class SomeBean {
>     private Logger log = new ConsoleLogger();
>     ...
> }
> So objecting about commons-logging not advocating IOC doesn't seem to make
> sense. 

So let me say the opposite: is Commons Logging advocating IOC?
What is the preferred method to get a Logger?

Come on, be fair. It's the static accessor.

> It'd be trivial to write a commons Log implementation that uses
> logkit if you're really concerned about logging integration - though for
> command line tools I'm not sure its worth it.


There is already. Do you actually look at the code you're talking about? ;-P

> Isn't it about time we merged logkit into commons logging?
> (ducks religious war)

No religious war. There is too much misunderstanding.

Logkit is not a facade, it's an implementation. We *are* talking about 
synergies with log4j though. We'll see.
And as for the framework part, it's going to be part of the A5 discussion.

>>And also that IMHO these small packages
>>should not log by default, since logging in these cases is not a runtime
>>requirement as in server applications but a debugging and development
> Why would a command line application thats using commons-logging be
> concerned about the IOC of the logger thats used by the main()? I can see
> this pro-logkit argument applying to other reusable components, but one
> thats tied to a command line tool (and so a stand alone application by
> definition) seems a bit of a leap.

We don't want a dependency on a package that has a static accessor to 
get a logger. You may not need it, but why not put this possibility at all.

If a user has Commons Logging in the classpath, and there is a conf 
problem, it's a PITA. In the server world, it really is.

>>It's ok if it uses Commons Logging, as long as it's not a hard
>>dependency. I think it's a good common ground, and it's what is done ATM.
>>I have personally committed Commons Logging in POI, and made it not
>>break the usage of the jar if not present, so should make it clear what
>>I think of the usage of Commons Logging in the scenario of reusable
> How did you do that? By writing yet another logging abstraction? :-)

We had our Logger with a worldful of utility methods for easy logging 
without having to +++ strings together by hand all the time.
I enable commons logging only if an environment property is enabled. 
Simple. And no users complaining about it not working for a logging 
package that is only for developers.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message