Daniel Fagerstrom schrieb: >>The ECM is given a LoggerManager that uses OSGi's LogService. We may >>consider using an optional LoggerManager service if present, as >>LogService has some limitations (no categories, and no isXxxEnabled >>methods). > > > The OSGi LogService is obviously a little bit limited. In the long term > we should have a LogService implementation in the Oscar project that > extends the OSGi LogService with the needed methods. Until then we could > either use the Knopflerfish extension of the LogService that at least > contains isXxxEnabled methods. Or, if someone feel like doing it, > implement an own LogService that fullfills our requirements, that we can > donate to the Oscar project later. > I think we should simply not use the OSGi LogService - we have the avalon logging infrastructure we can simply continue to use. We shouldn't change most of our core from one logging system to another.
> > Besides the Avalon context we have the Context in the environment, the > o.a.c.core.Core, o.a.c.core.Settings, > o.a.c.environment.internal.EnvironmentHelper that gives access to info > that at least to me seem to cover overlapping concerns. I wonder if > anyone in the community have a complete understanding of the intended > roles and lifecycles of all this. > I'm trying to move away from the Avalon context. The context will be replaced by the Core object and the settings object. While the settings object contains all "settings" :) (like configuration location, logging settings etc.), the core object is the Cocoon "core" :) The core provides access to various information as an official api. So basically everything which is not a setting. The EnvironmentHelper is an *internal* object which is just there to make the tree processor implementation a little bit easier/faster. It should not be used directly! Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
