On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:

> > In other words, you also want a 'push' model for the logger. Curently each
> > component is supposed to 'pull' the logger.
> 
> Pull?  From where?

Log log=LogFactory.getLog( MyObject.class )

( or by string ).

The current model used in log4j, jdk1.4, etc is pull - you request a 
logger by name. Same thing for jdbc connections, resources, etc.

> What's Log.getLog() ?
> 
> I am looking at o.a.c.l.Log and there is no getLog() method...

LogFactory.getLog(). It used to be a shortcut in Log too - my memory is 
overloaded at the moment.


> > +1 on the idea - but maybe we can discuss a bit the details. LogUser
> > and setCommonLogger sounds a bit weird, and I'm not sure I understand who
> > will call the method.
> 
> Here's the idea - we want to have a marker interface that a component (or
> tool, in our parlance) can implement such that any framework, container,
> code, app, thingy, servlet, (you get the idea) that supports commons logging
> can look for and invoke, handing the Log interface to the component to use.
> 
> If the container, framework, code...  doesn't support that, so be it.  No
> worries...  The component or tool won't log.

Just for the record, I think the default if no logger is explicitely set 
is to get a logger using the normal pattern.


> Ok.  This wouldn't change the Log interface - it would be an additional
> interface that is in fact optional - if a component/tool doesn't implement
> it, fine.  If a framework/servlet/app/etc doesn't look for it, fine...

It'll still be part of the exposed interface of commons-logger, which we 
try to keep minimal.

I'm +1 - except my comment in naming ( but I have no better names, so 
can't complain ).


Costin


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

Reply via email to