Hello, I have found a few points when I started to submit a patch. First I started with the JDK14Logger. The patch is ready, but the whole system should rely on the same behaviour, so I started to look at the other wrapper classes. AvalonLogger, LogKitLogger, Jdk13LumberjackLogger, and SimpleLog suffer from the same problem as described in the thread for JDK14Logger. Only Log4J12Logger and Log4J13Logger accept objects for messages, so there would be an problem in the underlying log4j which has to be resolved (I will put that on the log4j developer list.) It is a point of discussion if Log4J12Logger and Log4J13Logger should have the same null and exception safe behaviour as the others. I would recommend "yes" - what do you think?
AvalonLogger I looked at the website to find the correct jars to compile/test/build. Could someone provide the excat URL for downloading # logkit.jar - Avalon LogKit classes (see http://jakarta.apache.org/avalon) logkit.jar= # Avalon framework - used for wrapper for avalon framework logger avalon-framework.jar= please? Avalon seems to have reorganized their component structure and jars for different releases. It would be nice if the build.properties.sample would give more specific hints where to find the jars. (Am I blind?) Jdk13LumberjackLogger has a severe bug if I understand the logic correctly: There is an instance field private boolean classAndMethodFound = false; which is used to prevent creating the location information twice in getClassAndMethod(). This will work, if the instance is used by the default convention for logger names (org.foo.Classname). It will not work, if someone decided for logical categories like LOG.SYSTEM, LOG.DATABASE, LOG.CORBA or something. If i understand this method correctly it is also not threadsafe?! For all implementations: I like the current design of JDK14Logger. There is one private method which checks for the enabled level and if true puts the message (and throwable) to the underlying log system. So there is ONE place to modify the behavior. In most of the other implementations this functionality is spread all over the trace/debug.../fatal methods. If the underlying log system has a Level object (or Priority...) the design should be like in the JDK14Logger. What do think? Regards Boris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
