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: Components in blocks
Date Mon, 03 Oct 2005 09:59:12 GMT
Upayavira wrote:

> Daniel Fagerstrom wrote:

...

>> Another question is about ECM++ - OSGi service bridge. The idea with 
>> the bridge, as you might remeber, is that the the block has an ECM 
>> container that exports its components as OSGi services (see 
>> o.a.c.core.osgi.OSGiCoreServiceManager). This container has a parent 
>> container (o.a.c.core.osgi.OSGiServiceManager), that translates ECM 
>> lookups for components not defined in the block to OSGi service 
>> lookups that will get the components from another block.
>>
>> The OSGi services must be singletons, so ThreadSafe components can be 
>> exported and thanks to Carstens poolable proxy 
>> (o.a.c.core.container.handler.PoolableComponentHandler) also Poolable 
>> can be exported, but SingleThreadedComponents are not singltons and 
>> cannot be exported yet. For the components in cocoon-core.xconf all 
>> components could be exported except for FOM_JavaScriptInterpreter, 
>> the output modules and the PartSourceFactory, who are SingleThreaded.
>>
>> The question is how to solve it. Some of the SingleThreaded could 
>> probably be made ThreadSafe or Poolable, for the rest we could maybe 
>> have some kind of proxy. Ideas?
>
>
> You export a singleton Factory that is used to get the object. I guess 
> we could have the ECM++ bridge say "if this is component implements 
> ThreadSafe, return it, if it implements ComponentFactory (or some 
> such), return an object from its getInstance() method."
>
> That way the ThreadSafe/not ThreadSafe would remain transparent to 
> users of ECM++.
>
> Reasonable? Or have I missed something?

OSGi services are identified on what interface(s) they implement and 
optionally on extra properties. In the current implementation the role 
is the interface and the optional selector is a property. So that mean 
that the SingleThreaded would need to be identified in another way than 
on their role if we just register them as a generic factory. It would 
certainly be possible by having a property for the role as well for the 
SingleThreaded and let the lookup start with a query based on role as 
interface and if nothing was found, a query on the factory as interface 
and role as property.

But after that you helped me to clear my thought, I find a proxy 
solution more attractive. The proxy would implement the role interface 
and work as a factory. The question is still about how it should work. 
Proxies and details about the component manager is not my area of 
speciality. Thoughts? Or preferably an implementation ;)

/Daniel


Mime
View raw message