cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <>
Subject Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Date Wed, 15 Feb 2006 19:28:05 GMT
Hash: SHA1

On Wed, 15 Feb 2006, Carsten Ziegeler wrote:

> Date: Wed, 15 Feb 2006 14:20:12 +0100
> From: Carsten Ziegeler <>
> Reply-To:
> To:
> Subject: Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
> Ralph Goers wrote:
>> If that is the case then I'm -1 on this. We use our own logging framework
>> with Cocoon.
> I knew this would happen :) Ok, anyway, I would like to get rid off
> excalibur
> logging and logkit. Which means, we only use the o.a.a.logging.Logger
> abstraction which is passed to a component through LogEnabled. And we
> configure a Log4J logger by default for this abstraction.
> Now, with Spring I would suggest the following approach:
> Cocoon uses an own application context which can be compared (by
> simplifying) with a service manager. So we have an application context
> for the core of Cocoon (again simplified). Now you can define a root
> Spring application context using the usual Spring context listener and
> this one (if present) will be the parent context of our Cocoon core context.
> If you define your own logger bean in this spring application context,
> Cocoon will use that logger instead. If the spring app context is
> missing or does not define a logger bean we will define a log4j logger
> in the core application context. So it would be possible to use your own
> logging abstraction while Cocoon does nearly nothing to support it.

This is meant for traditional Avalon Components implementing LogEnabled, 

Anyway here's my +1 for it.

- -- 
Giacomo Pati
Otego AG, Switzerland -
Orixo, the XML business alliance -
Version: GnuPG v1.4.2 (GNU/Linux)


View raw message