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.

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

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director