incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Logging
Date Fri, 21 Apr 2006 11:48:42 GMT

-1 to defining our own logging API.   That is silly when there is a 
perfectly good logging API that meets the requirements  (logging 
requirements, not integration requirements), is very simple to use, that 
is already installed on everyones machines, does not have "version 
number" issues, etc...

Also, for all parts that are based on, use, or derive from Celtix, you 
will have to deal with JDK logging anyway.   All logging in Celtix is JDK 
logging.   Thus, the tools and bindings stuff might as well just use JDK 
logging since that is where a large number of the log messages are going 
to go anyway.    There is no plans (or desire) to change Celtix at this 
point.  It would be a lot of work for little/no gain.

How is this for an idea/comprimise:
For all logging, we use JDK Logger objects.   However, instead of calling 
Logger.getLogger(....), we create a utility class and call:
LoggerFactory.getInstance().getLogger(.....).  (several varieties of 
getLogger calls).   The default factory just passes them on to JDK Logger 
getLogger calls.   However, if you want, you can replace the 
LoggerFactory with one that will wrapper log4j Loggers or whatever else 
you want.   The JDK Logger object is not final (or have any final 
methods) so we can use it as the API for logging, the underlying logging 
can be just about anything.     I COULD be convinced to do something in 
similar in Celtix as this would JUST affect the Logger creation 
mechanisms, not any of the actual logging.

What are peoples thoughts about that?


> -1 for using JDK logging directly
> I detailed this in my earlier messages, the short version is that most
> people use/want/need log4j. Those people include myself for my apps at
> work. Since Geronimo uses commons logging I assume that G won't easily
> be able drop support for log4j either, but Geronimo commiters might
> have more details on that.
> /Lars

J. Daniel Kulp
Principal Engineer
P: 781-902-8727  C: 508-380-7194

View raw message