[
https://issues.apache.org/jira/browse/CAMEL-8273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14294756#comment-14294756
]
Claus Ibsen commented on CAMEL-8273:
------------------------------------
Yeah AFAIR the JDK xpath engine relies on working with DOM structures.
I have heard about custom xpath like engines that work with streams (not
supporting all of xpath, but covers most use cases anyway) but they were custom
made.
There is vtd-xml for example
http://camel.apache.org/vtd-xml
And the wso2 guys seems to have a custom streaming xpath engine in their
commerical esb
https://github.com/apache/synapse/tree/trunk/java/modules/core/src/main/java/org/apache/synapse/util
But not in the open source Apache synapse project
https://github.com/apache/synapse/tree/trunk/java/modules/core/src/main/java/org/apache/synapse/util
Notice how the streaming xpath compiler is missing at Apache.
Also not sure how far saxon can go with streams only
Some old SO questions
http://stackoverflow.com/questions/996103/streaming-xpath-evaluation
> More flexible selection of default documentType in XPath expressions
> --------------------------------------------------------------------
>
> Key: CAMEL-8273
> URL: https://issues.apache.org/jira/browse/CAMEL-8273
> Project: Camel
> Issue Type: Improvement
> Components: camel-core
> Reporter: Stephan Siano
> Assignee: Claus Ibsen
> Fix For: Future
>
> Attachments:
> 0001-CAMEL-8273-More-flexible-selection-of-default-docume.patch
>
>
> In the current implementation of XPath if no documentType is defined (likely
> in most cases) the document used for XPath evaluation is parsed into a (DOM)
> Document using the JDK XML parser before applying the XPath expression on it.
> For large documents this might be resource intensive, especially if the XPath
> is evaluated using a more efficient parser like Saxon.
> With the current implementation it is possible to workaround this by setting
> a documentType attribute to the XPath expression, but doing this efficiently
> requires some internal knowledge about the previous component in the camel
> route (which type it creates) and the qualities of the used XML parser (e.g.
> the JDK parser accepts only InputSource and Node as input types for XPath
> evaluation whereas Saxon does also support other types like SAXSource).
> The attached patch will make the data type used by default for XPath
> evaluation more flexible (depending on the type of the input).
> There are two cases to differentiate:
> documentType is set on the XPath expression:
> current implementation:
> 1. try to convert to the documentType
> 2. if that fails do some extra conversions for some additional data types
> (WrappedFile, BeanInvocation, String)
> 3. if that fails throw an exception
> new implementation:
> 1. try to convert to the documentType
> 2. if that fails, use the message if it is of type Node, InputSource or
> DOMSource or do some type conversions for specific data types (WrappedFile,
> BeanInvocation, String, InputStream, Reader, byte[]...)
> 3. if that fails throw an exception
> documentType is not set on the XPath expresson
> old implementation:
> this is actually the same as if documentType was set to Document
> new implementation:
> 1. Use the message if it is of type Node, InputSource or DOMSource or do some
> type conversions for specific data types (WrappedFile, BeanInvocation,
> String, InputStream, Reader, byte[]...) (to InputSource)
> 2. If the old message is not of one of the types above, convert to DOM
> Document
> 3. If this fails throw an Exception
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
