Initial ECM <-> OSGi bridge checked in

[Sylvain Wallez <sy...@apache.org>]

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

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://apache.org/~sylvain            http://anyware-tech.com
Apache Software Foundation Member     Research & Technology Director

Re: Initial ECM <-> OSGi bridge checked in

[Daniel Fagerstrom <da...@nada.kth.se>]

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

Re: Initial ECM <-> OSGi bridge checked in

[Carsten Ziegeler <cz...@apache.org>]

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/

Re: Initial ECM <-> OSGi bridge checked in

[Daniel Fagerstrom <da...@nada.kth.se>]

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