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