You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Giacomo Pati <gi...@apache.org> on 2006/02/13 14:34:15 UTC
Logkit (I know, again) was [RT] Using Spring instead of ECM++
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 13 Feb 2006, Carsten Ziegeler wrote:
> Once we use the Spring based container we can simplify the whole setup
> process and clean up things like the CoreUtil and the Cocoon class.
While we are at discussing cleanups.
What about also getting rid of logkit and use what we already have in
our dependency lists (log4J, commons-logging, ...)?
I think we definitively need to get a smaller footprint and also get
committed to fewer alternatives (of which we do have too many now IMHO,
not mentioning other stuff we carry with us just because we do have them
since years).
- --
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)
iD8DBQFD8IrdLNdJvZjjVZARAoi+AKCDTGanvWO2Hkz0nPOmRrw78qevKwCgnqft
fxZ9hMImd577AtnyHF1pYrA=
=gP3Y
-----END PGP SIGNATURE-----
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Reinhard Poetz <re...@apache.org>.
Upayavira wrote:
> Bertrand Delacretaz wrote:
>
>>Le 13 févr. 06, à 14:50, Carsten Ziegeler a écrit :
>>
>>
>>>Giacomo Pati wrote:
>>>
>>>
>>>>...What about also getting rid of logkit and use what we already have in
>>>>our dependency lists (log4J, commons-logging, ...)?
>>>>
>>>
>>>Yes, please :) I would suggest log4j as commons-logging has problems
>>>with classloading (afair) and noone is using jdk14 logging....
>>
>>
>>+1 for log4j
>
>
> +1 too.
I agree with you. log4j is the defacto-standard (at least in all my Java
projects it is used).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Upayavira <uv...@odoko.co.uk>.
Bertrand Delacretaz wrote:
> Le 13 févr. 06, à 14:50, Carsten Ziegeler a écrit :
>
>> Giacomo Pati wrote:
>>
>>> ...What about also getting rid of logkit and use what we already have in
>>> our dependency lists (log4J, commons-logging, ...)?
>>>
>> Yes, please :) I would suggest log4j as commons-logging has problems
>> with classloading (afair) and noone is using jdk14 logging....
>
>
> +1 for log4j
+1 too.
Upayavira
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Bertrand Delacretaz <bd...@apache.org>.
Le 13 févr. 06, à 14:50, Carsten Ziegeler a écrit :
> Giacomo Pati wrote:
>> ...What about also getting rid of logkit and use what we already have
>> in
>> our dependency lists (log4J, commons-logging, ...)?
>>
> Yes, please :) I would suggest log4j as commons-logging has problems
> with classloading (afair) and noone is using jdk14 logging....
+1 for log4j
-Bertrand
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Torsten Curdt <tc...@apache.org>.
On 14.02.2006, at 00:50, Carsten Ziegeler wrote:
> Giacomo Pati wrote:
>> On Mon, 13 Feb 2006, Carsten Ziegeler wrote:
>>
>>>> Once we use the Spring based container we can simplify the whole
>>>> setup
>>>> process and clean up things like the CoreUtil and the Cocoon class.
>>
>> While we are at discussing cleanups.
>>
>> What about also getting rid of logkit and use what we already have in
>> our dependency lists (log4J, commons-logging, ...)?
>>
> Yes, please :) I would suggest log4j as commons-logging has problems
> with classloading (afair) and noone is using jdk14 logging.
As a side note:
There is a new release of commons-logging coming out (rc is already
available) Simon and Robert claim that most of the classloading
problems have been solved. JCL has now extensive tests for classloading.
But as long as all libraries log into the same log file I don't care
anymore ...sorry, the logging discussion finally make me go "whatever!"
cheers
--
Torsten
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Upayavira <uv...@odoko.co.uk>.
Niklas Therning wrote:
> Carsten Ziegeler wrote:
>
>>
> ...
>
>>
>> Yes, please :) I would suggest log4j as commons-logging has problems
>> with classloading (afair) and noone is using jdk14 logging.
>
>
> Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a
> facade for other logging frameworks but it doesn't suffer from the
> classloading problems of commons-logging. It's used by the Apache
> directory project. I think it's being developed by the guy behind log4j.
We have discussed that before. Personally, just using the de-facto
standard of Log4J, if it is capable of meeting our requirements, keeps
things simple. And simple is something that Cocoon seriously needs to be
moving towards. We've been there and done that in relation to lots of
dependencies.
Regards, Upayavira
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Niklas Therning <ni...@trillian.se>.
Berin Loritsch wrote:
> Niklas Therning wrote:
>
>> Carsten Ziegeler wrote:
>>
>>>
>>> Yes, please :) I would suggest log4j as commons-logging has problems
>>> with classloading (afair) and noone is using jdk14 logging.
>>
>>
>> Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's
>> a facade for other logging frameworks but it doesn't suffer from the
>> classloading problems of commons-logging. It's used by the Apache
>> directory project. I think it's being developed by the guy behind log4j.
>
>
> Given the Avalon framework interfaces, we already have a log abstraction
> using the LogEnabled and Logger interfaces. Proper wrappers are also
> provided for Log4J and have been for years. There's no value add in
> introducing YALF (Yet Another Logging Facade).
>
>
> In the future when your components have no ties to Avalon, just use
> Log4J directly.
Yes, I wouldn't have a problem with that. Just wanted to mention slf4j
for those who hadn't heard of it before. But it seem like you guys
already been discussing these thing in the past (I wouldn't know since
I'm quite new to the list).
/Niklas
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 13 Feb 2006, Berin Loritsch wrote:
> Date: Mon, 13 Feb 2006 09:58:06 -0500
> From: Berin Loritsch <bl...@d-haven.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++
>
> Niklas Therning wrote:
>> Carsten Ziegeler wrote:
>> >
>> > Yes, please :) I would suggest log4j as commons-logging has problems
>> > with classloading (afair) and noone is using jdk14 logging.
>>
>> Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a
>> facade for other logging frameworks but it doesn't suffer from the
>> classloading problems of commons-logging. It's used by the Apache
>> directory project. I think it's being developed by the guy behind log4j.
>
> Given the Avalon framework interfaces, we already have a log abstraction
> using the LogEnabled and Logger interfaces. Proper wrappers are also
> provided for Log4J and have been for years. There's no value add in
> introducing YALF (Yet Another Logging Facade).
And we do have to maintain the contract mentioned interface requires for
backward compatability to the dozends of component we already have.
- --
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)
iD8DBQFD8KHDLNdJvZjjVZARAlaeAKCW4kkKDFgPq+v8NKVyWT6Q1LQ6jwCfec0w
cHmzs1ofZIwV5oHP8baHbLw=
=hG9K
-----END PGP SIGNATURE-----
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Berin Loritsch <bl...@d-haven.org>.
Niklas Therning wrote:
> Carsten Ziegeler wrote:
>>
>> Yes, please :) I would suggest log4j as commons-logging has problems
>> with classloading (afair) and noone is using jdk14 logging.
>
> Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's
> a facade for other logging frameworks but it doesn't suffer from the
> classloading problems of commons-logging. It's used by the Apache
> directory project. I think it's being developed by the guy behind log4j.
Given the Avalon framework interfaces, we already have a log abstraction
using the LogEnabled and Logger interfaces. Proper wrappers are also
provided for Log4J and have been for years. There's no value add in
introducing YALF (Yet Another Logging Facade).
In the future when your components have no ties to Avalon, just use
Log4J directly.
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Niklas Therning <ni...@trillian.se>.
Carsten Ziegeler wrote:
>
...
>
> Yes, please :) I would suggest log4j as commons-logging has problems
> with classloading (afair) and noone is using jdk14 logging.
Nowadays there's also slf4j (www.slf4j.org). Like commons-logging it's a
facade for other logging frameworks but it doesn't suffer from the
classloading problems of commons-logging. It's used by the Apache
directory project. I think it's being developed by the guy behind log4j.
Regards,
Niklas Therning
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Giacomo Pati wrote:
> On Mon, 13 Feb 2006, Carsten Ziegeler wrote:
>
>>> Once we use the Spring based container we can simplify the whole setup
>>> process and clean up things like the CoreUtil and the Cocoon class.
>
> While we are at discussing cleanups.
>
> What about also getting rid of logkit and use what we already have in
> our dependency lists (log4J, commons-logging, ...)?
>
Yes, please :) I would suggest log4j as commons-logging has problems
with classloading (afair) and noone is using jdk14 logging.
> I think we definitively need to get a smaller footprint and also get
> committed to fewer alternatives (of which we do have too many now IMHO,
Exactly :)
> not mentioning other stuff we carry with us just because we do have them
> since years).
So true!
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Giacomo Pati schrieb:
>>> 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?
>
Yes.
> Anyway here's my +1 for it.
>
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Giacomo Pati <gi...@apache.org>.
-----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 <cz...@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-----
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler wrote:
> 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.
>
> WDYT?
This works great for me! If the LogManager implementation can be
configured in Spring that would be awesome.
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
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.
WDYT?
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Ralph Goers <Ra...@dslextreme.com>.
Giacomo Pati wrote:
> -
> Can you explain how you use your own under Cocoon? Separate LogEnabled
> impls? CommonsLogging?
I implement org.apache.avalon.excalibur.logging.LoggerManager and
org.apache.avalon.excalibur.logging.Logger. These then interface with
my logging framework.
Ralph
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 13 Feb 2006, Ralph Goers wrote:
> Date: Mon, 13 Feb 2006 13:16:37 -0800 (PST)
> From: Ralph Goers <Ra...@dslextreme.com>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
>
> Carsten Ziegeler said:
>> Ralph Goers wrote:
>>> Carsten Ziegeler said:
>>> What do you mean by "always"? I thought that we switched the default
>>> from
>>> logkit to log4j a while ago? What more is needed?
>>>
>> This switch never happened - the idea behind this is to remove the
>> support for other logging frameworks completly. No more "you can use
>> this or you can use that or you can implement your own", but a simple
>> "use log4j".
>>
> If that is the case then I'm -1 on this. We use our own logging framework
> with Cocoon.
Can you explain how you use your own under Cocoon? Separate LogEnabled
impls? CommonsLogging?
- --
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)
iD8DBQFD8Q4hLNdJvZjjVZARAp62AJ92Hg0ekydAdKmzdwnZiG+dMQ4RCQCfYXsw
W/ed3irPnhqg09jTL9D9BvY=
=9wQc
-----END PGP SIGNATURE-----
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler said:
> Ralph Goers wrote:
>> Carsten Ziegeler said:
>> What do you mean by "always"? I thought that we switched the default
>> from
>> logkit to log4j a while ago? What more is needed?
>>
> This switch never happened - the idea behind this is to remove the
> support for other logging frameworks completly. No more "you can use
> this or you can use that or you can implement your own", but a simple
> "use log4j".
>
If that is the case then I'm -1 on this. We use our own logging framework
with Cocoon.
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Ralph Goers wrote:
> Carsten Ziegeler said:
>> Giacomo Pati wrote:
>>
>>> If the logger abstraction you mentioned is the Avalon LogEnabled one
>>> than yes, we will still have to support that for backward compatability.
>>>
>> Of course we will support LogEnabled - with the only difference that you
>> always get a wrapper around a Log4J (or whatever we decide) logger.
>
> What do you mean by "always"? I thought that we switched the default from
> logkit to log4j a while ago? What more is needed?
>
This switch never happened - the idea behind this is to remove the
support for other logging frameworks completly. No more "you can use
this or you can use that or you can implement your own", but a simple
"use log4j".
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Ralph Goers <Ra...@dslextreme.com>.
Carsten Ziegeler said:
> Giacomo Pati wrote:
>
>>
>> If the logger abstraction you mentioned is the Avalon LogEnabled one
>> than yes, we will still have to support that for backward compatability.
>>
> Of course we will support LogEnabled - with the only difference that you
> always get a wrapper around a Log4J (or whatever we decide) logger.
What do you mean by "always"? I thought that we switched the default from
logkit to log4j a while ago? What more is needed?
Ralph
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Carsten Ziegeler <cz...@apache.org>.
Giacomo Pati wrote:
>
> If the logger abstraction you mentioned is the Avalon LogEnabled one
> than yes, we will still have to support that for backward compatability.
>
Of course we will support LogEnabled - with the only difference that you
always get a wrapper around a Log4J (or whatever we decide) logger.
Carsten
--
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Mon, 13 Feb 2006, Ralph Goers wrote:
> Date: Mon, 13 Feb 2006 07:07:58 -0800
> From: Ralph Goers <Ra...@dslextreme.com>
> Reply-To: dev@cocoon.apache.org, rgoers@apache.org
> To: dev@cocoon.apache.org
> Subject: Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
>
> Giacomo Pati wrote:
>>
>> While we are at discussing cleanups.
>>
>> What about also getting rid of logkit and use what we already have in our
>> dependency lists (log4J, commons-logging, ...)?
>>
>> I think we definitively need to get a smaller footprint and also get
>> committed to fewer alternatives (of which we do have too many now IMHO,
>> not mentioning other stuff we carry with us just because we do have them
>> since years).
> I thought we already discussed this and made log4j the default? If that is
> the proposal, I'm fine with it. If the proposal means getting rid of our
> Logger abstraction layer I'm -1 on that.
If the logger abstraction you mentioned is the Avalon LogEnabled one
than yes, we will still have to support that for backward compatability.
- --
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)
iD8DBQFD8KJ6LNdJvZjjVZARAulkAJ0Td8xAWkSHgVvdBrS+QbiLy8RbuQCfdrV4
SRnldYHsPL4ohOutML/9h2k=
=zl97
-----END PGP SIGNATURE-----
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Ralph Goers <Ra...@dslextreme.com>.
Giacomo Pati wrote:
>
> While we are at discussing cleanups.
>
> What about also getting rid of logkit and use what we already have in
> our dependency lists (log4J, commons-logging, ...)?
>
> I think we definitively need to get a smaller footprint and also get
> committed to fewer alternatives (of which we do have too many now
> IMHO, not mentioning other stuff we carry with us just because we do
> have them since years).
I thought we already discussed this and made log4j the default? If that
is the proposal, I'm fine with it. If the proposal means getting rid of
our Logger abstraction layer I'm -1 on that.
Ralph
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
Posted by Sylvain Wallez <sy...@apache.org>.
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Mon, 13 Feb 2006, Carsten Ziegeler wrote:
>
>> Once we use the Spring based container we can simplify the whole setup
>> process and clean up things like the CoreUtil and the Cocoon class.
>
> While we are at discussing cleanups.
>
> What about also getting rid of logkit and use what we already have in
> our dependency lists (log4J, commons-logging, ...)?
>
> I think we definitively need to get a smaller footprint and also get
> committed to fewer alternatives (of which we do have too many now
> IMHO, not mentioning other stuff we carry with us just because we do
> have them since years).
+0.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://bluxte.net http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director