cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] The impact of using OSGi
Date Thu, 11 Aug 2005 15:12:48 GMT
Vadim Gritsenko wrote:

> Daniel Fagerstrom wrote:
>
>> Vadim Gritsenko wrote:
>>
>>> Daniel Fagerstrom wrote:
>>
<snip/>

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

To be a little bit more exact it is not actual components that are 
exposed but component factories.

> I feel that real block should be represented in OSGi as a single 
> 'Cocoon Block Service'.

That would IMO make the block architecture unnecesarilly monolithic. For 
exporting a sitemap service it makes sense to export some kind of Cocoon 
block service, we need a service that can take a request object and 
return a response object and above that fullfill some protocol for block 
attributes and polymorphic sitemap extension, that seem rather Cocoon 
specific.

But exporting components, why should that be part of the service that 
exports sitemap functionality? Furthermore, the concept of components is 
not specific to Cocoon even if their specific interfaces or container 
might be, so why should the registration an lookup of components 
(services) be tied to the sitemap functionality or something Cocoon 
specific whatsoever.

By making our block architecture as Cocoon agnostic as possible at the 
inter block level we makes it much easier to use it together with 
externally developed blocks (bundles). Also OSGi already have good 
mechanisms for service registration, lookup and event handling, no need 
to reinvent or circumvent it at the inter block level.

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

OSGi R3 does not have any concept of one bundle depending on another, 
they depend on and exposes packages.

> If you declare all of the components from all of the blocks, won't 
> they be available to everybody?

Only to those who import them. Furthermore there are Java security based 
mechanisms in OSGi for giving detailed access control between bundles, I 
have no idea about how it is used though.

> IIRC, block must not be able to lookup any other class, component, 
> pipeline from any other block but only from those wired to it.

At the class level you get something similar by declaring what packages 
the block import. At component level, you can connect a Map with any 
content to  a service, then you can use a subset of the LDAP query 
language on  these maps during lookup, so each component factory that is 
registred as an OSGi service could certainly be namespaced with a block 
name if we want to. Then the inter block component lookup mechanism can 
limit its search to blocks that are declared to be connected. Something 
similar can be used for refering to pipelines in other blocks.

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

As indicated above this can be solved without needing a monolithic 
Cocoon Block service. The advantage with not having such a central point 
is that it imposes less Cocoon specific restrictions on blocks and also 
that it makes it easier to use the mechanisms that allready are provided 
by OSGi for service register/unregister events.

>>> 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 :-)

Sure, there where some fine details to clarify though ;)

/Daniel


Mime
View raw message