[
https://issues.apache.org/jira/browse/SYNAPSE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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: https://issues.apache.org/jira/browse/SYNAPSE-213
> 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 processor:
> * 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
> http://xml.apache.org/xalan-j/dtm.html 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
