cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <>
Subject Re: [RT] Logging in 2.2
Date Wed, 05 Jan 2005 17:01:34 GMT
On Thursday 06 January 2005 00:43, Gianugo Rabellino wrote:
> On Wed, 05 Jan 2005 12:45:27 +0100, Carsten Ziegeler
> <> 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 

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 

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.

If you want the rainbow, you gotta put up with the rain.
 -  Steven Wright

|        |
|   |

View raw message