commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <>
Subject RE: [logging] Need interface...
Date Wed, 03 Apr 2002 19:32:54 GMT
> -----Original Message-----
> From: Craig R. McClanahan [] 
> On Wed, 3 Apr 2002 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 IoC based apps, the container.  period.  That is what IoC
is all about.  The container (or manager) makes all the decisions
about the component.

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

FQCN based logging is not fine enough :)

> 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() {
>     }
>   }

The container chooses the fine grained name.  Avalon makes the
balance quite well.  In fact, we can have loggers that are by 
functional unit--even below the class/component level.

> which creates a logger based on the fully qualified class name.
> 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" ...

LogKit also has those.

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

View raw message