On Thu, May 19, 2011 at 12:46 PM, David Blevins <[email protected]>wrote:
> The Logger class is maybe 10 years old. There maybe better ways to do > stuff now, but here's what it does... > > On May 18, 2011, at 5:50 AM, Shawn Jiang wrote: > > > 1, What's the benefit to use a customized logger factory with assigned > > category ? > > The i18n support is behind the logger API. Might be a more modern way to > do that these days. > > The categories are nice instead of packages as we occasionally move code > around between classes or packages and the configured log output remains > stable. Most the categories are used by several parts of the code which is > nice as it keeps things simple from a configuration perspective. > > Basically, most administrators don't care about the structure of our code > and don't want to be bothered when it changes. > One of important functions of log is for developer/L3 to locate where does the error happen. I used to use the class name in the log entry and "ctl +T" in eclipse to locate the class. But with the default category logging way, I have to use the logging message string as key word to search in full text to locate where does the log message come from. Maybe it's easy to turn on class/method displaying with log4j.properties in openejb. But I don't know how to do this for openejb in geronimo. > > > 2, What's the reason to use "org.apache.openejb.util.resources" > instead > > of the owner class name as the loggers' basename in most of classes ? > > That one is legacy. We should split up all those messages into the related > parts of code. > >From my understanding, we should change these "org.apache.openejb.util.resources" to the class name as a first step to improve them. > > As long as we're on the subject we should take another shot at switching > our default over to java.util.logging. If we can get the same output format > from java.util.logging and lose a log4j dependency, that could be nice. > > > -David > > -- Shawn
