cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakob Spörk <>
Subject RE: Our idea for simple StAX workflows
Date Wed, 10 Dec 2008 12:29:13 GMT
Hello Simon,

My name is Jakob Spoerk and I'm also member of the student group working on the Cocoon 3 StAX

Of course we are also thinking about combining SAX and StAX components because this allowa
to extend existing pipelines with StAX components and - what is even more important - it allows
to use SAX where this is better and StAX where this is better, so to use the best of both

Our main priority at the moment lies on StAX-only pipelines, because we can then build on
this implementation to allow the combination with SAX. At the current stage, we don’t plan
on having an automatism that allows to throw different SAX and StAX components in one pipeline
and "adapters" are set automatically between them. The developer will have to do this explicitly.
Our first idea at this topic is to build in a first step some kind of "envelope" that is itself
a StAX component but can be filled with one or more SAX components. The StAX->SAX interface
shouldn’t be that problem, because after pulling an event from the component before, the
envelope just fire the corresponding event in the first SAX component. The other end of the
envelop will require more "work", because we can't expect the event to really pass the SAX
components because maybe it is discarded or more events are build out of one, but we are very
optimistic to find also a simple way for this transformation. Using StAX components in SAX
pipelines will also be interesting, but at the moment, our priority lies on StAX-only pipelines
:) and we hope to present you a first prototype in the following days.

Best regards,

>Gute Morgen Andreas ;)
>very nice thoughts, congratulations :)
>I like your "backtracking" thoughts about StAX Pipeline component, I'm
>just curious reading the implementation and seeing how a SAX&StAX
>Pipeline works.
>Best regards... alles gute!
>2008/12/10 Andreas Pieber <>:
>> Hi,
>> 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
>> dependency.
>> 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
>> discarded.
>> 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:

My LinkedIn profile:
My GoogleCode profile:
My Picasa:
My Tube:

View raw message