commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: [CLI] new design possibly?
Date Thu, 06 Feb 2003 15:42:16 GMT
From: "Nicola Ken Barozzi" <>
> James Strachan wrote, On 06/02/2003 12.32:
> > From: "Nicola Ken Barozzi" <>
> > I see no reason why someone can't use Commons Logging in an IOC pattern
> > 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?

No - but then its not commons loggings place to dictate that, its up to the
component authors to do this.

e.g. digester uses an IOC approach to logging, take a look at the
setLogger(Log) method

> Every single package in Commons that uses CL uses the static accessor.

Lots of them use setter methods too. Using the static accessor is a handy
default when not using a full blown container to deploy beans in.

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

It is possible - see digester. Despite using commons logging, all commons
components could provide a mechanism for setting the Log and so implement

> > Whether there's an explicit LogEnabled marker interface or bean
> > introspection is used (I prefer the latter) makes little difference -
> > still IOC isn't it? Unless IOC is only IOC with explicit marker
> It's clear to me that you haven't looked at LogEnabled. It's not a
> marker interface.

I had looked very carefully. Sure its a non-empty interface (so I guess I
shouldn't have called it a marker interface) - however its only got one
method, which is not that useful - bean introspection could be used instead.
Afterall in IOC this would be invoked by a container which could easily
figure this out without this LogEnabled 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 );
> }

which could just be replaced by

    void setLogger(Log);

on any bean such as with Digester - no need for this interface for IOC.

> > Comparing commons logger and the logkit in Avalon Framework (and
> > their history for now) - they now look practically identical apart from
> > 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
> > 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
> implementations.
> 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.

OK. I frequently get confused by Avalon -  my mistake.

> 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.

How so? It looks mostly like just a different package name.

> 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
> > sense.
> So let me say the opposite: is Commons Logging advocating IOC?

No its agnostic. It doesn't advocate anything other than loose coupling to
any specific logging implementation.

> What is the preferred method to get a Logger?

Whatever a component developer wishes. Either IOC or a static method. i.e.
push or pull depending on how a component is developed & used.

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

The static accessor is in no way mandatory - its just how folks coming from
a log4j background tend to do things. There's nothing stopping IOC being
taken up on any commons component - there's no need to grok the whole IOC
thing and move to Avalon Framework to start using this pattern.

Also note that these same static accessor methods are right there in JDK 1.4
logging, log4j and logkit too.

In other words what I was trying to say in this thread was

* rejecting commons logging because it doesn't advocate IOC isn't a very
good argument - commons logging can be used in as much an IOC way as Avalon
Framework Logging and LogKit and indeed already is on some commons

* encouraging component authors to work with the IOC pattern of logging
(i.e. providing a setter method for Log) is a good thing, especially if that
component gets deployed in a container like Avalon etc.

> 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.

OK so I guess I'm talking about Avalon framework logging then.

> >>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
> >>requirement.
> >
> > 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
> > 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.

Why? You don't have to use it? Do you rule out JDK1.4, log4j and logkit as
well then?

> 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.

Only if its used that way. Like I said, this doesn't have to be the case.
Plus a container can install its own LogFactory and do all kinds of groovy
things if it wishes.

> >>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
> >>
> >>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
> >>components.
> >
> >
> > 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.

So are you talking about Avalon Framework logging here? Or logkit?

> 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.

Again which facade/API?


Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts

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

View raw message