Giacomo Pati wrote:
On Fri, 13 Jan 2006, Daniel Fagerstrom wrote:
Date: Fri, 13 Jan 2006 11:19:26 +0100
From: Daniel Fagerstrom <[EMAIL PROTECTED]>
...
block.xml contains or point to the block.xconf, so it can be place
anywhere.
I haven't found any formal specification about this "pointer to
block.xconf". The only thing I've found on the wiki if
COB-INF/block.xconf (so now META-INF/block.xconf).
AFAIK, the component management for blocks was never formally specified.
In the current implementation the ECM++ component declaration is just a
part of the block.xml, and by having an include element you can specify
an external configuration file.
Besides some trickery to get the contexts right for the involved
configuration files there is a parent component manager
o.a.c.blocks.InterBlockServiceManager that requests components from
service managers in blocks that are connected in the wiring.
Frankly, I find this overly complicated. I think we should instead have
a solution where the blocks still have own service managers, but that
they register their exported components in a global service registry.
This is the way it is done OSGi, so it will be forward compatible, and I
think it is enough. Using the wiring for component lookup seem FS to me.
...
Also, even if it isn't implemented yet, the idea is to make the
choice of component container configurable, something like:
...
<components
class="org.apache.cocoon.core.container.CoreServiceManager">
// Container specific configuration
</components>
...
Hmm.. the tricky part will be how to instantiate such a (unknown) FQCN
from the class attribute. This needs a formal interface which such
ServiceManagers must implements to allow the Deployer (or is it the
BlockManager) to initialize the component container.
It is the task of the BlockManager. Yes there will need to be a common
interface for ServiceManager bridges. Carsten (and maybe Sylvain) have
implemented part of what is needed for the Spring bridge that is used in
the tree processor.
So a default name isn't possible.
Except you only allow containers know to us and instead of a class
attribute you'll have a type (or whatever) attribute which you can
select from the implenetations we do have. Of course this way it isn't
individually extensible.
A contract for external containers seem more atractive.
/Daniel
