cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] The impact of using OSGi
Date Thu, 11 Aug 2005 13:50:53 GMT
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.
>>>> Why?
>>>> Do you have any specific design for achieving this that you are 
>>>> going to propose?
>>> May be I skipped important message - is there any reason why block's 
>>> classes has to import OSGi?
>> Yes. There are two main ways of handling blocks with OSGi, one 
>> passive way that I describe in 
>> and that we have implemented part of, for testing the concept, in the 
>> template block.
> How tis 'passive' way solves dynamic unloading of blocks? And 
> particularly I don't like 'build time configuration'. Does not sound 
> like real blocks to me. Moving on...

It is not that bad, some central blocks manager can register a listener 
for installation, update and uninstallation of bundles. It can then 
check the bundle that has change state for a configuration file and 
handle it accordingly: i.e. register its components, update them or 
unregister them. So it can be made dynamic, still it requires all 
packages to be exported and requires everything to be handled of the 
central component manager (ECM++). So it is not as scalable as the 
active approach.

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

> 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 

>> Sylvain have started to implement the later approach, see 
>> 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.

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



>> If we follow the passive approach all blocks need manifest files 
>> where all packages are exported. Also we need to implement some 
>> mechanisms for using the configuration from the block, (as described 
>> in more detail in the reference above).
>> In the active approach we need to continue the work that Sylvain has 
>> started, and we need to decide what to export from each block - 
>> everything or just the API.
> Best would be API only; if it makes prototyping easier - exporting 
> everything is Ok tradeoff for a time being.

We probably have to start by exporting about everything, but we should 
strive to refactor it to only export APIs.


>>                       --- o0o ---
>> We should IMO make a clear distinction between intra and inter block 
>> aspects: within current blocks we should not require any OSGi use, 
>> thing should work as before. But as inter block apects are 
>> essentially new functionallity we shouldn't beforehand limit 
>> ourselves and instead use the best technical solution available.
> To me 'best technical solution' should blend in inter block aspects 
> into ServiceManager (as additional syntax for role?

This is basically what is done in o.a.c.core.osgi, and there is a new 
"exported=true" attribute for exporting components from the block.

> or new component such as BlockManager?),

That is my idea for blocks with sitemap functionality, they have an 
internal BlockManager and exports a block service.

> possibly even without direct access to OSGi internals so that 
> implementation details of block management are hidden.
> As a side effect, blocks won't need much (if any) code changes 
> (package restructuring excluded).

That is the intension.



View raw message