[status] Blocks

[Daniel Fagerstrom <da...@nada.kth.se>]

Now the (non OSGi) blocks architecture contains block aware component 
handling as well as the sitemap functionality that I reported in [1]. 
Furthermore I have integrated the block functionality in Cocoon in such 
a way that Cocoon can be started in a blocks mode with:

  ./cocoon.sh blocks

Now the wiring.xml will set up the system rather than the cocoon.xconf.

This far only the core runs in block mode in the sample webapp. We need 
to discuss how to package and deploy the blocks into the main webapp. 
But at least the architecture for running them, as soon as they are 
deployed, is in place.

Also the blocks architecture need both more desing discussion and 
various code improvements. But now we have a starting point.

The work described here is not (yet) integrated with OSGi. It is focused 
on the blocks functionallity that should be part of 2.2.

The big picture for blocks can be found in [2,3].

Examples
========

Take a look at the test code: 
src/test/org/apache/cocoon/test/blocks/BlocksManagerTestCase, and start 
with wiring.xml. Here most of the mechanisms described in [1] are used 
as well as the blocks aware component handling.

Also the src/webapp use blocks. Start with wiring.xml and 
WEB-INF/block.xml. Here webapp both acts as a container for all blocks 
with the wiring.xml (that point at a webapp block located at .) and as a 
block with WEB/block.xml as blocks descriptor.

Component handling
==================

Much of the Cocoon functionality assumes that a special Core component 
is available. To handle this I added a "core" attribute with default 
value false to the component section in block.xml. When the core 
attribute is set to true the block will create a Core object and put in 
its exposed component container. The "core" block must be created first 
as all other blocks depends on it.

Each block that has a component section in block.xml will export the 
components declared in that section to all blocks that are wired to it.

When a component is looked up in a block first the own container is 
searched, and if the component isn't found there, the connected blocks 
will be searched in the order they are declared in blocks.xml. The super 
block (if there is one) will be searched last.

Roles are not implemented for the inter block component handling, all 
used roles must be redeclared in the block that uses them. We should 
have some mechanism to be able to export roles. But as roles are rather 
Avalon specific I would prefer if we could find a more container neutral 
weay of handling roles between blocks. IMO we shouldn't asume that all 
blocks use ECM++ internally for managing  their exported components.

Architecture
============

Most parts of the (non OSGi) blocks architecture is found in the package 
o.a.c.blocks. The main classes are BlocksManager, that is configured 
with wiring.xml, sets up and keep track of all the blocks and switched 
the processing to the right block. There is also one BlockManager for 
each block.

BlocksManager
-------------

The BlocksManager implements Processor and work as a replacement for the 
Cocoon object when Cocoon is used in blocks mode. I have refactored the 
CocoonServlet and CoreUtil, so that they handle a Processor rather than 
having explicit references to the Cocoon class. By setting the new 
settings property "org.apache.cocoon.processor" to 
"org.apache.cocoon.blocks.BlocksManager" rather than the default value 
"org.apache.cocoon.Cocoon", Cocoon will be used in blocks mode. 
Furthermore the "org.apache.cocoon.configuration" setting must be set to 
point to the wiring.xml rather than the default cocoon.xconf.

The BlocksManager set up one BlockManager per block based on the 
wiring.xml and have methods for getting a block based on its identity 
and a (mounted) block based on a URL, these two methods will be factored 
out to an interface.

The BlocksManager also sets up a BlockDispatcherProcessor that does the 
actual processing.

Right now the BlocksManager has a little bit to wide concern area IMO. 
This is partly to make it compatible with the Cocoon object. When we 
have polished the blocks architecture we should IMO get rid of the 
Cocoon object and only have one starting point for Cocoon. After that we 
can have better SoC.

BlockManager
------------

The BlockManager represent a block its main purpose is to setup and put 
together various aspects of the block functionality. Due to the way it 
is integrated in the rest of Cocoon it contain more functionality than I 
would like it to.

The classes that a block consist of is:

* BlockWiring - that represent the wiring and the block.xml for the block.

* BlockContext - that implements o.a.c.environment.Context. Its main 
responsiblities is to take care of the block local context URI and it 
makes the block deploy time attributes avialable as init parameters. 
Right now it is not connected to the container context, but we could 
change that if it is needed.

* IterBlockServiceManager - acts as root ServiceManager in a block 
(except for the "core" block). It search the connected blocks for a 
component that isn't found in the own block. Currently it have a flawed 
protection about circular search for components in the case where blocks 
has circular dependencies. Help is needed to get it right and efficient. 
IIRC this problem was solved in Fortress, anyone knowing how?

* o.a.c.components.source.impl.BlockSource, 
o.a.c.components.module.input.BlockPropertyModule, 
o.a.c.components.module.input.BlockPathModue and 
o.a.c.environment.internal.BlockEnvironmentHelper - are also involved in 
the blocks architecture. Here nothing have changed, so I refer to [1].

* BlockProcessor - Embeding of the main sitemap of thew block.

Much of the work in the setup of the BlockManager is about cretaing a 
SourceResolver that has the right root context within the block. This is 
a rather disturbing property of the current SourceResolver functionality 
in Cocoon that I would like to solve like I described in [4]. As can be 
seen in that thread we have differnt opinions about how to solve the 
problem.

Further development
===================

What we need to do now is to get the current implementation usable and 
stable enough and to get the contracts at the configuration level and 
directory organization level right.

We also need to take care of packaging and deployment. Specify the 
packaging format, make M2 create  blocks and write block.xml to all our 
current blocks.

Later I would like to make the block architecture independent of the 
component container and maybe even of Cocoon. It should be possible to 
use other containers that ECM++ within a block. Also I'd like to make 
the choice of processor within a block pluggable so that people can 
develop blocks without needing to make them sitemap based. A block could 
for example use Berin's RoR inspired processor or maybe a pure flow 
script processor instead. Or maybe an web service processor.

And of course it should be migrated to OSGi.

                      --- o0o ---

WDYT?

/Daniel

[1] [Ann/RFC] "Sitemap Blocks", 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111791016006393&w=2
[2] Cocoon Blocks presentation, 
http://www.cocoongt.org/Slides-and-recordings.html
[3] http://wiki.apache.org/cocoon/Blocks
[4] Problems with lazy loading components, 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=112971800718572&w=2