Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Wed, 15 Feb 2006 20:28:05 +0100 (CET)
From: Giacomo Pati <giacomo@apache.org>
Sender: giacomo@lapgp.otego.com
To: dev@cocoon.apache.org
Subject: Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
In-Reply-To: <43F32A8C.2060402@apache.org>
Message-ID: <Pine.LNX.4.64.0602152026450.17119@lapgp.otego.com>
References: <43E8F7FF.4070304@apache.org> <43E9CB85.9020605@mobilebox.pl>  
     <43ECB985.7060500@reverycodes.com> <43ECDDC9.8070909@apache.org>      
 <43ECE244.2040109@apache.org> <43F083FD.3040908@apache.org>      
 <Pine.LNX.4.64.0602131430330.10461@lapgp.otego.com>      
 <43F0A0CE.5040903@dslextreme.com>
       <Pine.LNX.4.64.0602131614010.10461@lapgp.otego.com>
       <43F0A6F4.3070703@apache.org>   
 <1e920a4432a17f4ea24730a.20060213104314.enycu.tbref@www.dslextreme.com>   
 <43F0D8D3.20607@apache.org>
 <1e100a4310a178f0a23d80a.20060213131637.enycu.tbref@www.dslextreme.com>
 <43F32A8C.2060402@apache.org>
X-GPG-PUBLIC_KEY: 
 http://pks.gpg.cz:11371/pks/lookup?op=get&search=0x2CD749BD98E35590
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Virus-Scanned: ClamAV version 0.88,
 clamav-milter version 0.87 on smtp-07.tornado.cablecom.ch
X-Virus-Status: Clean
X-DCC-spamcheck-02.tornado.cablecom.ch-Metrics: smtp-07.tornado.cablecom.ch
 32701;
	Body=1 Fuz1=1 Fuz2=1
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

-----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 <cziegeler@apache.org>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> 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-----