Sylvain Wallez wrote:
Hi all,
I committed an initial ECM <-> OSGi bridge in
src/org/apache/cocoon/core/osgi.
Cool!
This code is untested and there are still some pending points, but I
wanted to share it ASAP so that we can discuss these issues.
What we have there is a ServiceManagerActivator that will create an
ECM++. In this ECM, components that have exported="true" on their
configuration are registered as OSGi services.
Also, the parent of this ECM is an OSGiServiceManager that looks up
non-local components as OSGi services.
Ok
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.
The main pending point is the avalon context for the created ECM.
Cocoon places a lot of environment-related information there that I
currently don't know where to get from. Maybe this should be obtained
from the Cocoon core bundle?
It could possibly be exposed as a service from the Cocoon core bundle.
At some point we need to take a deeper look at the various contexts in
Cocoon. One of the major hurdles during my various core related work the
last months have been to understand (or rather not break :/ ) context
info in Cocoon.
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.
At least we need to write documentation on how all this works, so that
not each person that try to do core work needs to read tons of code to
"understand" this mess. Preferably we should refactor it to something
more comprehensible.
Sorry for my rant about Cocoon internals, but I have spent weeks in
fighting with them.
--- o0o ---
Anyway, cool work. The next step, as soon as we have found a way to get
the context info, should be to apply the stuff on some suitable block.
/Daniel
