commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@optonline.net>
Subject Re: [logging] Need interface...
Date Wed, 03 Apr 2002 19:32:18 GMT
On 4/3/02 2:20 PM, "Craig R. McClanahan" <craigmcc@apache.org> wrote:

> 
> 
> On Wed, 3 Apr 2002 costinm@covalent.net wrote:
> 
>> 
>> The current model used in log4j, jdk1.4, etc is pull - you request a
>> logger by name. Same thing for jdbc connections, resources, etc.
>> 
> 
> In fact, there's an important philosophical issue about logging here as
> well -- who gets to choose the name of the logger (and therefore the log
> level)?

In this case, it's you, the container.

> 
> The trend I've seen the most is that logger names are fine grained - often
> based on the fully qualified class name of the class that is doing the
> logging.  This means that I can turn on debug logging on just my "foo"
> component, without having to turn on debugging info for all the components
> that are sharing the same Log instance.  To say nothing of the fact that I
> can direct the log output from different components to different places
> ...

Using the *optional* LogUser interface, you can choose where things log to -
you pass the 'channel' to the component in the setCommonsLog() method that
you want it to use - so in debugging, you pass it the logger for debugging -
for production, you give it a less chatty one, or none at all.

> 
> Bottom line is that I would be unlikely to create components that
> implemented LogUser or whatever, even if it did get added.  It takes away
> too much fine-grained control for my taste.  The pattern I like is similar
> to what Jon quoted:
> 
> public class MyComponent {
> 
>   private static Log log = LogFactory.getLog(MyComponent.class);
> 
>   public void hello() {
>     log.info("Hello!");
>   }
> 
> }
> 
> which creates a logger based on the fully qualified class name.
> 

But now you've lost control as the container, or as the container, you have
to do all the work in LogFactory.

The other way, you can create some set of loggers and pass them to the
components when you, the app/framework/servlet/woogie instantiate them...

I think it's a wash - and I can implement your pattern with mine, so it
isn't a wash - imagine the app is creating/loading components :

  foreach( class to instantiate)
  {
    Object o = Class.forName(classname).newInstance();

    if (o implements LogUser)
    {
        Log log = LogFactory.getLog(o.getClass());
        ((LogUser) o).setCommonsLog(log);
    }
  }

So there I get your pattern exactly - so I can localize my per-class logging
in LogFactory *or* also have local control in the component loading :


  foreach( class to instantiate)
  {
    Object o = Class.forName(classname).newInstance();

    if (o instanceof "o.a.c.l.LogUser")
    {
        // don't do it for class foo.bar as its too blabby

        if(!(o instanceof "foo.bar"))
        {
            Log log = LogFactory.getLog(o.getClass());
           ((LogUser) o).setCommonsLog(log);
        }
    }  
  }

> Further, at least for Log4J and JDK 1.4 logging (and perhaps others) have
> nice inheritance rules about logging names, so that you could turn on
> debug level output for *all* Commons components that use this pattern by
> setting the level for "org.apache.commons" ...

I don't see how that's taken away - you still can do that...

-- 
Geir Magnusson Jr.                                     geirm@optonline.net
System and Software Consulting

Maven & Gump are friends


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message