commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <>
Subject Re: [logging] Need interface...
Date Wed, 03 Apr 2002 16:12:25 GMT
On 4/3/02 10:55 AM, "" <> wrote:

> On Wed, 3 Apr 2002, Geir Magnusson Jr. wrote:
>> What we need is a marker interface that indicates a tool wants a logger, and
>> of course a method to give it the logger...  I did a quick scan of the
>> public API, and there doesn't seem to be one.
>> So what I propose is to add an interface 'LogUser' or something like it (we
>> can quibble about the name...)
>>  public interface LogUser
>>  {
>>     public void setCommonsLogger(Log log)
>>  }
> In other words, you also want a 'push' model for the logger. Curently each
> component is supposed to 'pull' the logger.

Pull?  From where?

> Well, I can't say no. I prefer the current Log.getLog() pattern, but
> the whole point of commons is to be open and accept multiple points
> of view, instead of forcing everyone to use a 'right' thing.

That's "Right ThingĀ".  Get it right :)

What's Log.getLog() ?

I am looking at o.a.c.l.Log and there is no getLog() method...

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

> In JMX terms, you would have a method setLogger( o.a.commons.logger.Log )
> or setLoggerName( String ) and based on some config JMX will set the
> logger. The Log???? interface will be extended by the component
> MBean interface ( if any ). Seems a valid use case, and a good idea to
> 'standardise' the pattern used to set the logger in a component.

Right - I used the methodname 'setCommonsLogger()' because 'setLogger()' is
just so generic, I didn't want to cause undue conflict with other methods a
Class would have to implement.

> Maybe even a set logLevel() to tune the ammount of output the component
> generates - i.e. a second filter pattern. I wouldn't say no, since the
> pattern is in wide use in tomcat(3 at least, and other projects as well )
> and quite usefull.

Ok - I'm game, as long as I can ignore it :)

>> As I personally believe that just being a commons committer doesn't give me
>> the 'spirit-of-the-law' right to commit to the logger, I'll ask for some
>> even vague hint of approval from the logger people before moving forward.
> Good idea, given the amount of debate we had for each API change in
> commons-logger. I would do the same.
> However feel free to commit anything in the impl :-).

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

Kinda harmless.  Just want to get it right...

Geir Magnusson Jr.                           
System and Software Consulting
"The greatest pleasure in life is doing what people say you cannot do."
        - Walter Bagehot

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

View raw message