geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Logging problems
Date Tue, 09 Nov 2004 19:31:58 GMT
On Nov 8, 2004, at 10:49 PM, Bruce Snyder wrote:

> Dain Sundstrom wrote:
>> I've thought about this, but it would mean that our code is locked to 
>> a single log solution.  This means that is someone wanted to swipe 
>> our transaction manager they would have to use log4j (for example).  
>> If we instead follow the example of mx4j and use a single simple log 
>> interface anyone would be able to adapt it to their logging system.
> Build only what we need now, don't get hung up on all the possible 
> what-if scenarios. Unless the what-if scenario is a driving factor. I 
> haven't seen or been part of any discussions where architecture was 
> driven by 'someone [who] wanted to swipe our tx mgr'. (Yes, I'm being 
> a smart ass ;-))

I have been part of several discussions, where someone mentioned they 
wanted to use just one part of our server.  Each time questions like 
what do you use for logging, lifecycle and such come up.  Anyway, I 
don't think there is any reason to use one log interface over another, 
especially when you consider how easy it is to write an adapter.

>>> Please use only Log4J for all Geronimo logging.
>> :)  I wasn't going to go there.  There are many people that think we 
>> should use java.util.logging.  I personally think we should shoot for 
>> an IOC solution where the integrator of the components (the Kernel in 
>> our case) gets to choose the logging system.
> Tell me more about the IoC solution. I like the sound of it. But I 
> definitely do *not* like the java.util.logging remark.

BTW, people do like it.  I have been asked on more then one occasion 
why we don't just use util.logging directly instead of commons-logging, 
and I always respond with a comment about the guy on the other side 
arguing that we go to log4j directly.

As of an IoCish solution.... If we changed our components to declare a 
dependency on a Log, the kernel can initialize a log and inject it into 
the component.  For example, instead of a component using this code to 
get a log:

public class MyService {
     private static final Log log = LogFactory.getLog(MyService.class);

     public MyService() {"Blah");

You do this:

public class MyService {
     private final Log log;

     public MyService(Log log) {
         this.log = log;"Blah");

The key here is code is not directly accessing a LogFactory.  This 
allows us to provide a log implementation that connects to any log 
framework.  It also allows the container add additional information to 
the log events under the covers of the interface, such as the object 
name of the component.


View raw message