cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Upayavira>
Subject Re: Components in blocks
Date Mon, 03 Oct 2005 09:29:37 GMT
Daniel Fagerstrom wrote:
> I have continued the work that Sylvain started on ECM++ - OSGi service 
> bridge, and have some questions.
> 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.
>                      --- 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.
> 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?


View raw message