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?

/Daniel

Reply via email to