Thorsten Scherler schrieb:
El mié, 03-12-2008 a las 08:56 +0100, Sylvain Wallez escribió:
Andreas Pieber wrote:
...
One big "problem" in this approach is that the "flow direction of events" is
completely inverted. This means that StAX and SAX components would not be able
to work "directly" together. But also in a push-pull approach a conversion
between StAX and SAX events have to be done and further more this problem could
be tackled by writing a wrapper or adapters around the SAX components and add
them to an StAX pipe.
Absolutely. Converting Stax to SAX is fairly trivial, but the other way
around requires buffering or multithreading. Have you looked at
Stax-Utils [1]? It contains many classes to ease the SAX <-> Stax
translation.
I lately played around (and still do) with such approach in the forrest
dispatcher rewrite [3]. I am using Axiom which is a quite interesting
approach and maybe worth looking into [4]. However I did some profiling
and for the dispatcher the old SAX approach had been ways faster.
We started with an evaluation of some StAX implementations including
Axiom, WoodStox and the reference implementation.
However quite early we felt that the DOM-like approach of Axiom is not
ideally suited for our current phase.
I'm quite sure that there are occasions where Axiom can be really
charming, but I believe there are too many premises required to
efficiently use it (e.g. you will want to be sure that the XML data is
not too large). But if you have some complex transformation that appear
to difficult to be implemented in a one-pass approach Axiom could
probably do the trick.
I'm sure we will explore this idea at a later time, though...
However this is due to the buffering issue pointed out by Sylvain which
[5] is not solving at all. Brings me back to do a sax (+stax) approach
again (the other class in the package).
I am really exited about this thread. :)
I must admit that it got me all excited by now, too.
Yesterday, I did a very minimalistic POC, just to make sure our current
approach is not missing any major point.
I have to say I was simply amazed how easy state handling can be when
using StAX compared to SAX and I'm very confident that we came up with a
pretty thorough concept.
After all, we tortured our poor students more than a month with
evaluating implemenations, writing uses cases - outside Cocoon! - using
both SAX and StAX, before even "allowing" them to think about how to
integrate this into Cocoon.
I believe this was necessary to fully understand the differences between
StAX and SAX and - even more important - the different usage patterns
associated with them.
And I'm sure this allows us now to fully reap the benefits of this API.
Well, I can't wait to see the first components ...
salu2
...
[1] http://stax-utils.dev.java.net/
[2] http://www.flickr.com/services/api/response.rest.html
[3]
https://svn.apache.org/repos/asf/forrest/branches/dispatcher_rewrite/plugins/org.apache.forrest.plugin.internal.dispatcher
[4] http://ws.apache.org/commons/axiom/OMTutorial.html
[5]
https://svn.apache.org/repos/asf/forrest/branches/dispatcher_rewrite/plugins/org.apache.forrest.plugin.internal.dispatcher/src/java/org/apache/forrest/dispatcher/transformation/DispatcherWrapperTransformer.java
