Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
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, SN 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++
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, SN 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++
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++
-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: 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-
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++
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, SN 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++
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 smime.p7s Description: S/MIME cryptographic signature
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
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++
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++
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 WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: Logkit (I know, again) was [RT] Using Spring instead of ECM++
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++
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++
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++
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++
-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 [EMAIL PROTECTED] 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++
-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 [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org, [EMAIL PROTECTED] 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++
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, SN 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++
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++
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, SN 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++
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++
-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 [EMAIL PROTECTED] 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++
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++
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 PGP.sig Description: This is a digitally signed message part
