Re: [VOTE] CommonsLogger.java (was: cvs commit: ...)

[Nicola Ken Barozzi]

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

Correct.

 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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]