cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Components in blocks
Date Mon, 03 Oct 2005 13:35:44 GMT
Sylvain Wallez wrote:

> Daniel Fagerstrom wrote:
>> I have continued the work that Sylvain started on ECM++ - OSGi 
>> service bridge, and have some questions.
> Great!
>> I start with a simpler one about component configuration. The idea is 
>> that the block.xml have an optional component section which declares 
>> the components that the block exports (see webapp/WEB-INF/block.xml 
>> for an example). One can use the attribute exported="false" for 
>> private components. The reason for not using the component section of 
>> the sitemap for declaring the components that the block exports is 
>> that blocks doesn't have to contain a sitemap, some are "component 
>> only" blocks.
>> As the "sitemap components" of a block in most cases also should be 
>> exported, so that they can be used in other blocks, the components in 
>> the webapp sample sitemap and in WEB-INF/sitemap-additions also need 
>> to be included from the repective block.xml. As it is a waste of 
>> resources to declare them again in the container of the main sitemap 
>> of the blocks it means that I want to move all components of the main 
>> sitemap in the sample webapp and all components 
>> inWEB-INF/sitemap-additions to the respective WEB-INF/xconf. Is this 
>> OK, or are there any problems? If it is OK, I do it ASAP for the 
>> webapp samples.
> Sounds reasonable, and won't change things much: components are kept 
> in a separate file, and it's just the include location that changes, 
> right?


>>                      --- o0o ---
>> 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.
> I refactored PartSourceFactory it so that is is now ThreadSafe. I also 
> had a quick look at the output modules, and it seems that none of them 
> has a state, meaning they could be made ThreadSafe as well.

They have a state, settings, in the abstract base class.

>> 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?
> FOM_JavaScriptInterpreter must be kept SingleThreaded because, 
> although being actually reentrant, each sitemap must be given a single 
> instance. For this particular case, we can change to a factory 
> pattern, the factory being threadsafe.

Can you give some more details about how?


View raw message