On Thursday 06 January 2005 00:43, Gianugo Rabellino wrote: > On Wed, 05 Jan 2005 12:45:27 +0100, Carsten Ziegeler > > <[EMAIL PROTECTED]> wrote: > > In the past we had several arguments about why logkit is better and so > > on but I think most of these arguments are not valid any more. > > Well, AFAIU a big one still stands true: security. I really hate the > idea that other code can write to my channel just by doing a > Logger.getLoggerFor().
There is also a slight issue with Log4J in its dealings with runtime dependencies and classloading that may hurt future efforts in Cocoon in "true blocks". Ex, If I have a running instance and decides to change the Log4J configuration to include an Appender that has an additional runtime dependency (javamail for instance) than is available from the Logger classloader (which they recommend to be the most top level CL one can manage to put it in), then you will need to bring down the entire server. This is the result of missing separation of interface and implementation, missing classloader strategy and total lack of IoC, and during Merlin days we were trying hard to stop depend on LogKit and make a full port to Log4J, but the work seemed overwhelming and the Log4J folks were a bit lost of why this is a problem for long-running applications. I also agree with Nicola's pointer of the problems with commons-logging, and to use it, you will need to throw away the factory and use your own IoC pattern, but then, that is essentially same as the current Logger interface... Maybe just throw away (Abstract)LogEnabled and do constructor injection instead. Or even relegate Logging to an ordinary service, which is looked up like any other component. Cheers Niclas -- --------------- If you want the rainbow, you gotta put up with the rain. - Steven Wright +---------//-------------------+ | http://www.dpml.net | | http://niclas.hedhman.org | +------//----------------------+
