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
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.
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.
/Daniel
