commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: [logging] Need interface... VOTE
Date Fri, 05 Apr 2002 15:17:44 GMT
On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote:

> >>   o.a.c.genericlog.Log
> >>   o.a.c.genericlog.LogUser
> >>   o.a.c.genericlog.LogFactory
> > 
> > You already have 2 of them ( Log and LogFactory).
> In o.a.c.l with some implicit assumptions (which I am trying to dodge...)

It's quite explicit, and your proposal seem to hava a LogFactory too.

BTW, are you going to also propose a o.a.c.genericxmlparser, 
o.a.c.genericjdbc, etc ? After all, there are few dozen APIs using the 
same pattern with common-logging, do you feel confused when using them 
too ? 

> > What about 
> > o.a.c.logmanager.LogUser - define the interface to be implemented by
> > components who want to support setLog()
> > o.a.c.logmanager.LogManager - define interface for setting the
> > properties if a Log, like level, appenders - the minimal stuff that is
> > common to all loggers.
> > (maybe few others ).
> That would be cool - but setLog() sets the factory, so you can recover the
> pull model as well w/o giving anything up.

Fine with me.

BTW, since static LogFactory.getFactory() uses per ClassLoader data ( so 
each application can use a different factory ), we should also add a 
static setFactory() method in LogFactory itself. This way you can change 
explicitely the default factory for the whole application with a single 
call ( instead of calling each compoent's setLog()).

Again, I'm perfectly fine and +1 if you want to set the factory on each 
component, maybe you want to use multiple loggers in your app.

> > I would be +0 on this ( I think the push and management APIs should be
> > part of c-l itself, not a separate package ).
> I do to, but it seems to me that the underlying implementation assumptions
> of o.a.c.l are somewhat at odds with the notion of implementation-free
> generic interface...

Can you give any arguments for that ( besides 'it seems' ) ?

Is there anything in Log that is not implementation-free ? Is there any 
requirement to use Log with a named-based pull system or force ? 
( or even to force it's use with LogFactory ).

LogFactory is a helper for people who want a one-line init code
for logging. It does some magic to guess what logger is in the classpath,
and that's it. I wouldn't use anything more complex - if using 
commons-logging requires implementing an interface or creating setters, 
then I prefer to use println.   


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

View raw message