cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] The impact of using OSGi
Date Thu, 11 Aug 2005 16:34:20 GMT
Vadim Gritsenko wrote:

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

According to the OSGi specification, a service is a singleton for a 
given bundle: different bundles _can_ be given different objects for the 
same services, but a given bundle will always obtain the _same_ object 
when it asks for a service.

What that means is that only components exposed as singletons can be 
exported as OSGi service and thus between blocks. This means ThreadSafe 
components that already have the singleton semantics and also poolable 
components wrapped in a ThreadSafe proxy that is available in ECM+

When exporting components as OSGi services, the OSGiCoreServiceManager 
registers an OSGi ServiceFactory that wraps an ECM ComponentHandler 
after having controlled that this handler actually manages a singleton.


> Hm... I think you are mixing three concerns here in one:
>   (1) How cocoon block obtains classes exported from non-cocoon,
>       pure OSGi block

Classes are obtained as usual by using them (classloader stuff). 
Services are obtained by the good old 
ServiceManager.lookup(ServiceInterface.class.getName()) which is 
implemented as an OSGi service lookup.

>   (2) How cocoon block obtains *component* (not class! not factory!)
>       exported from another cocoon block

ServiceManager.lookup() ! The factory stuff is hidden in 

>   (3) How non-cocoon, pure OSGi block obtains components exported by
>       cocoon block

Cocoon components are exported as OSGi services using their role, which 
happens to be the name of the service interface, as required by OSGi. 
For components having multiple implementations, the hint is stored in 
the OSGi property dictionary used to register the service.

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

Well, it seems to me we have the 3 of them right now :-)


Sylvain Wallez                        Anyware Technologies
Apache Software Foundation Member     Research & Technology Director

View raw message