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
--
Sylvain Wallez Anyware Technologies
http://people.apache.org/~sylvain http://www.anyware-tech.com
Apache Software Foundation Member Research & Technology Director
