synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andreas Veithen (JIRA)" <>
Subject [jira] Resolved: (SYNAPSE-213) Improve handling of input in XSLTMediator
Date Mon, 24 Mar 2008 15:47:24 GMT


Andreas Veithen resolved SYNAPSE-213.

    Resolution: Fixed

XSLTMediator now uses Spring's StaxSource for the transformation source when useDOMSourceAndResults
is false.

> Improve handling of input in XSLTMediator
> -----------------------------------------
>                 Key: SYNAPSE-213
>                 URL:
>             Project: Synapse
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.1, NIGHTLY
>            Reporter: Andreas Veithen
>            Priority: Minor
>             Fix For: 1.2
> Currently XSLTMediator uses two different strategies to feed the XML input into the XSLT
> * When useDOMSourceAndResults is set to false, the Axiom tree will be serialized to a
byte stream (in memory or to a temporary file for large documents) and then fed into the XSLT
processor using a StreamSource object.
> * When useDOMSourceAndResults is set to true, the code will call ElementHelper.importOMElement
to get a DOM compliant version of the Axiom tree. The resulting DOM tree is then passed to
the XSLT processor using a DOMSource.
> First it should be noted that using a temporary file for the XML input (in contrast to
the output of the transformation) doesn't eliminate the need to keep the entire input document
in memory. Indeed:
> * When the input is read, Axiom will built the entire tree and keep in memory.
> * Due to the way XSLT works, the XSLT processor also requires a complete in-memory representation
of the input document. The only exception is for XSLT processors that supports streaming,
which is not the case for Xalan. Xalan uses its own object model called DTM (Document Table
Model) to store the input document in memory.
> Since the input document must be kept in memory anyway, the only question is how to efficiently
feed the original Axiom tree into the XSLT processor without creating too much overhead and
consuming too much memory. Assuming that Xalan is used, the current situation is as follows:
> * When useDOMSourceAndResults is set to false, three copies of the XML input will be
built: the Axiom tree, the serialized byte stream and Xalan's DTM representation. When temporary
files are used for large documents, only two will coexist in memory. However, using temporary
files introduces a large overhead.
> * When useDOMSourceAndResults is set to true, at least two copies of the input will be
built: the Axiom tree and the DOM tree. Indeed, from the code in ElementHelper.importOMElement
it can be seen that an entirely new copy of the input tree will be created. In addition, Xalan
will create a DTM representation of the DOM tree. The document at
suggests that this representation is not a complete copy of the DOM tree, but a wrapper/adapter
that is backed by the original DOM tree.
> Both strategies used by XSLTMediator are far from optimal. There are at least two strategies
that should give better results (with at least one of them being actually simpler):
> * Trick Axis2 into producing a DOM compatible tree from the outset, by using a StAXSOAPModelBuilder
with a DOMSOAPFactory (this produces objects that implement both the Axiom and DOM interfaces).
This however might require some tweaking. The advantage is that there is no need to create
a copy anymore. Xalan will only create a DTM wrapper around the existing tree.
> * Make sure that a DTM representation is created directly from the Axiom tree without
intermediate copy (byte stream or DOM tree). With Java 6/JAXP 1.4 this would be very easy
because it has support for StAXSource, which integrates nicely with Axiom. In the meantime,
the solution is to pull StAX events from Axiom, convert them to SAX events and push them to
the XSLT processor. The Spring WS project has a utility class StaxSource (extending SAXSource)
that does this in a completely transparent way (new StaxSource(omElement.getXMLStreamReader())).
By using getXMLStreamReaderWithoutCaching instead of getXMLStreamReader, this could probably
be further optimized to instruct Axiom not to create the tree for the part of the input message
that is being transformed (unless it has already been constructed at that moment).

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message