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() {
log.info("Blah");
}
}You do this:
public class MyService {
private final Log log; public MyService(Log log) {
this.log = log;
log.info("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.
-dain
