cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Exploring Corona
Date Fri, 21 Mar 2008 17:17:37 GMT

Today I have added Corona to our whiteboard section in SVN 
( It mostly mimicks 
the existing concepts of pipelines and sitemaps as you know from Cocoon 2.x. The 
available test cases are a good starting point to explore the sources. We also 
hope that this email explains some of our ideas.

What does already work?


So far we have created a (minimalistic) pipeline API (o.a.c.c.pipeline.Pipeline 
[1]) that works based on two fundamental concepts:

1. The first component of a pipeline is of type
    o.a.c.c.pipeline.component.Starter. The last component is of type

2. In order to link components with each other, the first has to be
    a o.a.c.c.pipeline.component.Producer, the latter
    a o.a.c.c.pipeline.component.Consumer.

When the pipeline links the components, it merely checks whether the above 
mentioned interfaces are present. So the pipeline does not know about the 
specifc capabilities or the compatibility of the components.
It is the responsibility of the Producer to decide whether a specific Consumer 
can be linked to it or not (that is, whether it can produce output in the 
desired format of the Consumer or not). It is also conceivable that a Producer 
is capable of accepting different types of Consumers and adjust the output 
format according to the actual Consumer.

There are SAX-based components that implement these concepts.

These concepts are more general than the implementation of Ccooon 2.x which has 
explicit methods to set generators, transformers, serializers and readers on 


The sitemap engine works similar like Cocoon 2.x. The 
o.a.c.c.sitemap.SitemapBuilder reads XML and creates a tree of 
o.a.c.c.sitemap.node.SitemapNode objects that know their parent node, their 
child nodes and their parameters.

The o.a.c.c.sitemap.node.AbstractSitemapNode handles the node relationships and 
parameters in a general way.
However there are two annotations (@o.a.c.c.sitemap.node.annotations.NodeChild 
and @o.a.c.c.sitemap.node.annotations.Parameter) to make the access of specific 
child nodes and parameters more explicit.
The ChildNode annotation can be used to store a certain child node in a separate 
member variable instead of the collection of all children (e.g. 
o.a.c.c.sitemap.node.PipelineNode receives its ErrorNode in the errorNode member 
The Parameter annotation works the same way, but causes parameters to be stored 
in separate member variables (e.g. o.a.c.c.sitemap.node.MatchNode receives its 
pattern in the pattern member variable).

When the sitemap is being executed, the invocation traverses the tree of 
SitemapNodes. Each node returns a o.a.c.c.sitemap.node.InvocationResult that 
indicates the execution state. This is one of NONE, PROCESSED, and COMPLETED:

* NONE means that the node did not do any processing whatsoever (e.g. a 
MatchNode did not match).

* PROCESSED means that the node did some processing, but the traversal should 
continue (e.g. the GenerateNode installed a Generator at the pipeline; but some 
other components might still be pending)

* COMPLETED means that the node did some processing and the traversal should 
stop, since the invocation processing is completed (e.g. the PipelineNode 
executed the pipeline)

Nodes that act as a switch (e.g. MatchNode, ErrorNode, etc.) aggregate the 
individual results of their children.
So a MatchNode will respond with NONE if and only if all of its children return 
NONE, and with COMPLETED otherwise.


When a pipeline and then further the sitemap is invoked, the execution context 
is passed. Since context has so many different meanings to us, we called this 
execution context o.a.c.c.sitemap.Invocation. It contains input parameters, 
sitemap parameters and a component provider and gives access to the result.

Since the sitemap should be useable in any environment, the Invocation doesn't 
have any environment specific dependencies (e.g. the Servlet API). Hence, the 
input parameters are a general map. However, our idea is that environment 
specific parameters (e.g. the HTTPRequest) can be put into this map too and can 
be made accessible by an accessor helper class.
So if a component needs access to environment specific parameters e.g. the 
HTTPRequest, it uses the appropriate accessor helper class. All components and 
accessor helper classes that belong to a certain environment (iow. are not 
generally available) should be bundled together. This creates a core module that 
is useable in any environment and additional modules for specific purposes.

Since the sitemap shouldn't depend on a specific component container, the 
o.a.c.c.sitemap.ComponentProvider as an abstraction for specific containers, was 
introduced. So far we have implemented a o.a.c.c.sitemap.SpringComponentProvider 
that encapsulates all Spring bean lookups. It should be fairly easy to write 
implementation for alternative containers (e.g. OSGi).

What needs to be done?

So far the package and module structure doesn't reflect all the ideas from 
above. For now we have prefered to keep the things simple.

The sitemap language hasn't been completed so far. We also think that we should 
take this as a chance to tidy up a few things (e.g. map:match vs map:select, 

There are still many components missing. For our needs we will work on the 
XSLTTransformer and the IncludeTransformer.

There is no support for other expression languages (e.g. JEXL, JXPath) than the 
"map" language.

We want to introduce support for controllers, however, we are not sure if this 
should be a environment specific concept or should only go into a servlet 
specific module. (So far we don't have any use case for it outside of a web 

Caching pipelines are not supported yet.

As I said (, our goal 
is to get the Micro-Cocoon test sitemap[2] working.

We hope that this gives you enough hints in order to understand Corona. We are 
very interested in further discussions. So fire at will!

Reinhard & Steven

[1] o.a.c.c -> org.apache.cocoon.corona

Reinhard Pötz                            Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair

View raw message