cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: Block deployment: working with blocks from a user's point of view
Date Fri, 13 Jan 2006 13:07:11 GMT
Giacomo Pati wrote:

> On Fri, 13 Jan 2006, Daniel Fagerstrom wrote:
>> Date: Fri, 13 Jan 2006 11:19:26 +0100
>> From: Daniel Fagerstrom <>

>> 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.


View raw message