avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [VOTE] CommonsLogger.java (was: cvs commit: ...)
Date Sun, 09 Feb 2003 10:39:35 GMT

Paul Hammant wrote, On 09/02/2003 11.23:
> Leo,
>> I thought I'd draw some more attention to this as it seems like this 
>> might be a contentious issue and it should not be in the way of a 
>> 4.1.4 release (ie if this turns out to be contentious I'll remove the 
>> class again for now).
>> I just wrote and committed a single class, 
>> org.apache.avalon.framework.logger.CommonsLogger, which implements 
>> Logger by (trivially) wrapping around commons-logging. I also added in 
>> proper conditionals in the build so that things build properly if 
>> commons-logging is not available.
>> Like all code, it is subject to a lazy consensus vote. If you don't 
>> want CommonsLogger in 4.1.4 (despite the sound arguments below :D), 
>> please say so ASAP so any discussion isn't in the way of a 4.1.4 
>> release. I don't want to steamroll this in.
> The class is fine, but let us not market it as Commons logging in 
> Avalon-Framework.  This is what /they/ want :-
>  public class Foo {
>      private static final Log logger = LogFactory.getLog(Foo.class);
>     // other methods          static {
>          logger.info("yee haaa");
>      }
>  }

 From the discussion on commons-dev it does not seem so.
Some commons packages already have a setLogger() method... they ask for 
a choice, to be able to use commons-logging as a target for 
avalon-framework-using components.

Anyway, is someone wants to do the above he can anyway. What he cannot 
do without this code is using commons-logging in a proper 
Avalon-framework type IOC manner.

> We have not engineered a solution, just a delegate that is instance 
> orientated :-


>  public Foo implements  LogEnabled {
>      Logger logger;
>      pubic void enableLogging(Logger logger) {
>          this.logger = logger;
>      }
>      static {
>          // whoops can't do logging here.
>      }
>  }
> So -1 .. it adds nothing that we did not have already.

I understand what you mean. We already have facades, why put in a facade 
to a facade that does the same thing our facades do?
In fact, why not deprecate our facades and use the commons logging ones?

Talking about the "real" solution, it would seem that it would involve 
these steps:

  1) Utility packages like jakarta commons ones use commons-logging.
     It's the easiest and most sensible solution for fine grained stuff.

  2) Avalon Framework uses commons-logging as the facade for logging to
     different implementations. This means that coarse-grained components
     keep using AF4-compatible IOC.

  3) Every Avalon container registers it's own LogFactory as a top-level
     LogFactory, so that it intercepts *all* logging calls and can deal
     with them in a centralized way, somewhat inverting the control.


Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message