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 10:25:57 GMT
Sylvain Wallez wrote:

> Hi all,
> I committed an initial ECM <-> OSGi bridge in 
> src/org/apache/cocoon/core/osgi.


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


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


View raw message