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 16:14:30 GMT
Daniel Fagerstrom wrote:
> Vadim Gritsenko wrote:
>> Daniel Fagerstrom wrote:
>>> 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.

This does not look like a good idea at all. In many scenarios, service 
(Threadsafe Component) must really be instantiated once in order to work 
properly. Cron, RunnableManager, DatasourceComponent come to mind.

There is of course set of components which can be instantiated multiple times - 
Poolables and SingleThreaded.

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

Or sitemap InvokeContext and return ProcessingPipeline. Whatever.

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

So just I better understand your point, how do you envision Batik Block 1.0 and 
Batik Block 2.0 register SVGSerializer service in the OSGi container?

And how consumer which knows he is wired to Batik Block 'Latest Release' finds it?

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

It shouldn't be tied to anything Cocoon specific. Just get ServiceManager and 
make a lookup for anything you are wired to - and you are done :-)

And anything you are not wired to is not available (otherwise mess ensues).

Hm... I think you are mixing three concerns here in one:

   (1) How cocoon block obtains classes exported from non-cocoon,
       pure OSGi block
   (2) How cocoon block obtains *component* (not class! not factory!)
       exported from another cocoon block
   (3) How non-cocoon, pure OSGi block obtains components exported by
       cocoon block

I suggest to ignore the third and concentrate on second. Third can come later - 
if ever - if need arise - and can be implemented as you describe it, by 
exporting each component as a 'service'. First is necessary only if you want to 
package some .jar files as blocks or use 3rd party blocks, also can be ignored 
for the time being.

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

As long as you can mix and match those bundles. IIRC, one of the main 
requirements for the real blocks is the ability to have two different versions 
of same block used in two other blocks, simultaneously.

And any additional block deployment should not change what other blocks are 
seeing / using - avoid side effects.

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

As long as it helps to reach the goal - fine.

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

How conflicting packages are handled.

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

How you pick version of the package you need.

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

If it's done once when block is loading - fine. Not sure it's ok for each 
component lookup though.

> Something 
> similar can be used for refering to pipelines in other blocks.

You can't refer to 'pipeline' - only to sitemap.

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

I think advantage of single point of entry is simplification of code & more 
efficient runtime. It seems easier to connect one ECM+* to another ECM+* by 
passing a reference than doing all those LDAP queries.


View raw message