-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wed, 15 Feb 2006, Carsten Ziegeler wrote:
Date: Wed, 15 Feb 2006 14:20:12 +0100
From: Carsten Ziegeler <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
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,
right?
Anyway here's my +1 for it.
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFD84DLLNdJvZjjVZARAjIqAKDmSaZJp+Ulj5r5edAbe7dNDot/HQCgoztp
nC3wMxOtnN103AF7Wju6Dgc=
=HhsQ
-----END PGP SIGNATURE-----
