cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [RT] The impact of using OSGi
Date Thu, 11 Aug 2005 14:22:06 GMT
Daniel Fagerstrom wrote:
> Vadim Gritsenko wrote:
>> Daniel Fagerstrom wrote:
>>> Vadim Gritsenko wrote:
>>>> Daniel Fagerstrom wrote:
>>>>> Vadim Gritsenko wrote:
>>>>>> I'd even say that at this point in time, none of the existing 
>>>>>> blocks should be aware of OSGi existence but only Cocoon "Kernel",

>>>>>> which uses OSGi to manage (load/unload) blocks on the fly.
>>>>> Do you have any specific design for achieving this that you are 
>>>>> going to propose?

But in the end we do agree as it seems :-)


>>> And one active way, where the block contain an own component manager 
>>> and an component manager <-> OSGi bridge.
>> Obviously, each block contains (at least) one sitemap. Each sitemap 
>> creates own component manager. So we have this covered.
> You are running ahead ;) we are only talking about "component only" 
> blocks yet.

So they can have root component manager then :-)

> This far there have not been much discussions about how to 
> add the sitemap aspect to the OSGi based architecture. I have some ideas 
> about how to achieve it and will write an RT about it. In my design a 
> block that provides sitemap functionality will register a block service 
> that then can be used by a central blocks manager block. A block will be 
> able to have any mix of passive library export, active component export 
> and export of sitemap services.
> So some blocks will contain a sitemap but for most of the current ones 
> that doesn't make sense as they only export compinents. Ok, in some 
> sense we can achieve that by having a sitemap without pipeline sections.

Or root component manager :-)

>> Obviously, component manager has to interoperate with OSGi in order to 
>> get handle on 'parent' component manager ('Parent' here in quotes 
>> because component lookup strategy for that parent manager should 
>> change from what we have today.)
>> So no surprise here.
> This is allready to a large extent implemented, take a look at 
> o.a.c.core.osgi.


>>> In the active approach the inter block component handling is handled 
>>> through OSGi services. To be able to register a service the block 
>>> needs an OSGi Activator class.
>> (minimally, i'd think block only needs to register it's component 
>> manager service, everything else you can get from it)
> There are two main alternatives: register the component manager as a 
> service or register the components as services. We found the later 
> alternative more atractive as OSGi allready contains a nice and flexible 
> service registration and service lookup mechanism. Adding an extra layer 
> just seemed to complicate things.

Not sure it will fly, though.

First, it means that you are managing 'fine' components with coarse container. I 
feel that real block should be represented in OSGi as a single 'Cocoon Block 

Second, block is wired to several other blocks, and all (java classes, 
components, pipelines) it can see must be either in the Cocoon Core or in one of 
the blocks which are wired to it.

If you declare all of the components from all of the blocks, won't they be 
available to everybody? IIRC, block must not be able to lookup any other class, 
component, pipeline from any other block but only from those wired to it.

So at the time of block loading, 'block(s) loader/manager' can lookup Cocoon 
Block service instances for all blocks referenced from this one, and pass these 
services to the block, and after that block can lookup everything it needs 

>> The Cocoon Kernel will have to have an 'OSGi Activator', but not each 
>> block. You are not seriously planning to force each block developer to 
>> start creating their own activators, right? It's implemented once in 
>> kernel, and referenced across all blocks.
> Yes

That was my point - blocks won't have OSGi code :-)



View raw message