[
https://issues.apache.org/jira/browse/CAMEL-9534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karsten Blees updated CAMEL-9534:
---------------------------------
Attachment: xmlparserbench.7z
Here's a simple JMH-based micro benchmark to test the performance of StAX vs.
SAX. Bottom line is that for plain XML parsing, StAX is slightly faster than
SAX, especially for small documents. However, using StAXSource with XSL
transformations sucks quite badly, as both the default TrAX implementation
(XSLTC) and Saxon convert to a push style API internally. This will probably
not change in the near future, as transformers need to support both APIs and
StAX can easily be converted to SAX, but not the other way around.
> XsltComponent: fix support for Saxon-B (and Woodstox)
> -----------------------------------------------------
>
> Key: CAMEL-9534
> URL: https://issues.apache.org/jira/browse/CAMEL-9534
> Project: Camel
> Issue Type: Bug
> Components: camel-core, camel-xslt
> Affects Versions: 2.11.4, 2.12.3, 2.13.0, 2.14.0
> Reporter: Karsten Blees
> Attachments:
> 0001-CAMEL-9534-XsltComponent-set-default-of-allowStAX-op.patch,
> 0002-CAMEL-9534-XsltComponent-fix-support-for-Saxon-B-and.patch,
> xmlparserbench.7z
>
>
> AFAIK Saxon-B is the only XSLT 2 processor that supports Java extensions
> (that's why it is still available for download on the Saxon site).
> CAMEL-7130 enabled the "allowStAX" option by default, which is not supported
> by Saxon-B. This also breaks handling of CDATA sections with the Woodstox
> StAX implementation.
> CAMEL-7753 tries to configure Saxon's MessageWarner class via a proprietary
> Saxon API that seems to change frequently - the current code only works with
> Saxon 9.3 - 9.5 (see also CAMEL-7891, CAMEL-8830).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
