cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <>
Subject Our idea for simple StAX workflows
Date Wed, 10 Dec 2008 11:24:55 GMT

Since Reinhard introduced us to the community we have worked quite hard on our 
first prototype for a StAX based cocoon pipeline and are now ready to present 
our thoughts about how StAX could be used in cocoon.

Of course there are many possible ways to do such an implementation. Some of 
them as multithreading, continuation and others were already named by Sylvain 
and Thorsten.

Before presenting our ideas, or discussing already mentioned ideas we want to 
state the intention and the goals of this project as we think about.

First of all we do not want to replace SAX. In our opinion StAX should only 
allow a developer to solve problems requiring a quite complex state handling in 
SAX in an easy and (more or less ;) ) intuitive way to work it. Further more we 
also want new cocoon developers to be able to use/write cocoon StAX-Pipelines 
within a few hours, by keeping it as simple as possible and providing examples 
to make it very easy to adopt them to their own problems.

We are Sylvains opinion that it is possible to build StAX pipelines by using 
continuation. But this approach would add several disadvantages as handling the 
"break points", additional dependencies, increasing the complexity for developer 
and maybe continuation adds more problems than it solves. Since we have another 
approach how to do it in a more simple way we think we shall avoid continuation.

Most of the disadvantages of continuation are also valid for multithreding. 
Additional it could happen that developers, using many components, could reach 
the thread pool limit.

We started with this project by evaluating different StAX implementation. Namely 
Woodstox[1], Axiom[2], and the JSR reference implementation included by the jaxp 
packages in the JDK6.

Finally we come to the following conclusion:

Woodstox: More or less the reference implementation, but adds an additional 

Axiom: As already mentioned by some people in the mailing list axiom is a nice 
idea, but would add too much complexity at this stage of the project.

JSR reference implementation: Comes for "free" and with an acceptable speed. 
Thats the one we decided for.

First of all our implementation does not change any of the existing cocoon 
interfaces. Neither do it changes the appearance to the user (especially the 
usage) .

Due to the nature of pull parsing, internally we are proposing an inversion of 
control as following:

Starting the pipeline the Starter propagates the initialization of the pipeline 
through the components to the finisher. From therefore the finisher pulls the 
elements from its parent and writes them directly to the output. This pull is 
than propergated back through all components.

Cause of the nature of the XMLEventIteratorApi every pull produces a resulting 
XMLEvent object representing the actual node. Actually this reduces the problem 
is reduced to simple objects which could be easily added, modified and 

We hope we put our thoughts on display understandably and looking forward 
hearing your thoughts.

Andreas, Michael, Jakob and Kilian 

SCHMUTTERER+PARTNER Information Technology GmbH

Hiessbergergasse 1
A-3002 Purkersdorf

T   +43 (0) 69911127344
F   +43 (2231) 61899-99
mail to:

View raw message