cocoon-dev mailing list archives

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

> 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?
> 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 "settings" Map is initialized in configure() which is part of the 
Avalon creation methods. It's therefore not actual state, as it isn't 
changed by any of the services methods. So they can be made ThreadSafe IMO.

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

Well, either we define a specific FlowInterpreterFactory interface, or 
we define a generic factory service in ECM++, which will be analogous to 
what already exists in both OSGi (ServiceFactory) and Spring (BeanFactory).


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

View raw message