cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Initial ECM <-> OSGi bridge checked in
Date Wed, 10 Aug 2005 12:50:02 GMT
Carsten Ziegeler wrote:

>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 
>>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.
I'm not talking about changing anything within core. The idea is to use 
a LoggerManager implementation that in turn uses an OSGi LogService, see 
o.a.c.core.osgi.OSGiLoggerManager. By using the OSGi LogServce at that 
level we automatically logs that are marked with what bundle it origins 
from and also a standardized API for accessing the log info. This log 
info can in turn be used from e.g. an OSGi console bundle (graphic or 
command line).

>>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.
I appriciate that you work on tidying things up, still non circular 
definitions of the concern areas would help ;)

>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!
I know that it is internal, it is still important when you work on the 
internals, so its role in relation to other context info needs to be 
clarified. Also the combination of dependecy injections in terms of 
context and core and static information in terms of the 
EnvironmentHelper, makes things harder to follow. Also the static 
EnvironmentHelper makes it much more complicated to write unit testing 
code for core components. So I'm starting to think that it is a design 
mistake to have it.


View raw message