camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Karsten Blees (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CAMEL-9534) XsltComponent: fix support for Saxon-B (and Woodstox)
Date Sat, 30 Jan 2016 14:04:39 GMT

     [ https://issues.apache.org/jira/browse/CAMEL-9534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Karsten Blees updated CAMEL-9534:
---------------------------------
    Attachment: xmlparserbenchStaxSource.7z
                0004-CAMEL-9534-XmlConverter-use-a-pool-of-SAXParser-XMLR.patch
                0003-CAMEL-9534-optimize-attribute-handling-in-StAX2SAXSo.patch
                0002-CAMEL-9534-XsltComponent-fix-support-for-Saxon-B-and.patch
                0001-CAMEL-9534-XsltBuilder-always-convert-StAXSource-to-.patch

I had another look at the [StaxSource|https://github.com/apache/camel/blob/master/camel-core/src/main/java/org/apache/camel/converter/jaxp/StaxSource.java]
class introduced in CAMEL-7130. Turns out it already handles CDATA correctly (in contrast
to the JDK's StAXStream2SAX adapter). After optimizing the attribute handling a bit, StaxSource
+ SJSXP is almost as fast as SAX. However, StaxSource + Woodstox leaves SAX far behind.

So I believe the best solution is to stick with {{allowStAX=true}}, but always use StaxSource
instead of relying on the TrAX implementation's StAX-to-SAX adapter. I've updated the patches
and benchmark accordingly.

Would it make sense to upstream patches 1 and 3 to {{org.apache.cxf.staxutils.StaxSource}}?

> 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-XsltBuilder-always-convert-StAXSource-to-.patch,
0002-CAMEL-9534-XsltComponent-fix-support-for-Saxon-B-and.patch, 0003-CAMEL-9534-optimize-attribute-handling-in-StAX2SAXSo.patch,
0004-CAMEL-9534-XmlConverter-use-a-pool-of-SAXParser-XMLR.patch, xmlparserbench.7z, xmlparserbench100Threads.7z,
xmlparserbenchStaxSource.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)

Mime
View raw message