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/
