XSLT
JVM since0.4.0 Native since0.4.0
Transforms XML payload using an XSLT template.
What’s inside
-
XSLT component, URI syntax:
xslt:resourceUri
Please refer to the above link for usage and configuration details.
Maven coordinates
Or add the coordinates to your existing project:
<dependency>
<groupId>org.apache.camel.quarkus</groupId>
<artifactId>camel-quarkus-xslt</artifactId>
</dependency> Check the User guide for more information about writing Camel Quarkus applications.
Additional Camel Quarkus configuration
In native mode, XSLT templates are compiled to Java classes at build time, so the extension needs to know the locations of the XSLT templates. The XSLT source URIs have to be passed via the quarkus.camel.xslt.sources property. Multiple URIs can be separated by comma.
quarkus.camel.xslt.sources = transform.xsl, classpath:path/to/my/file.xsl Scheme-less URIs are interpreted as classpath: URIs.
Only classpath: URIs are supported on Quarkus native mode. file:, http: and other kinds of URIs can be used on JVM mode only.
In JVM mode, templates are compiled at runtime and quarkus.camel.xslt.sources is not required.
Compiling more than one template requires the native build to run on JDK 21.0.8 or newer.
<xsl:include> is supported in native mode when the including stylesheet is listed in quarkus.camel.xslt.sources and included stylesheets are classpath-relative. Nested classpath includes are resolved at build time. <xsl:messaging> XSLT elements are supported in JVM mode only right now.
If aggregate DSL is used, XsltSaxonAggregationStrategy has to be used such as
from("file:src/test/resources?noop=true&sortBy=file:name&antInclude=*.xml")
.routeId("aggregate").noAutoStartup()
.aggregate(new XsltSaxonAggregationStrategy("xslt/aggregate.xsl"))
.constant(true)
.completionFromBatchConsumer()
.log("after aggregate body: ${body}")
.to("mock:transformed"); Also, it’s only supported on JVM mode.
Configuration
TransformerFactory features can be configured using following property:
quarkus.camel.xslt.features."http\://javax.xml.XMLConstants/feature/secure-processing"=false Features are applied to every template the component transforms with, whether it was compiled to a translet at build time or loaded at runtime. A feature the TransformerFactory does not support fails endpoint creation.
| Disabling secure-processing permits templates to call extension functions, and is logged as a warning on startup. Only do this where every template the application transforms with is trusted. |
External access
The extension transforms with the XSLT implementation built into the JDK. Secure-processing is enabled and access to external DTDs and stylesheets is denied:
-
A document being transformed that reaches the transformer as a
javax.xml.transform.Sourceand references an external DTD or an external entity fails the transformation. -
Resources referenced by
<xsl:import>,<xsl:include>and thedocument()function are denied unless ajavax.xml.transform.URIResolverresolves them. The component installs a resolver for the templates it compiles and on every transformer it uses, so routes resolve them as they do on plain Camel.
These restrictions remain in place when secure-processing is disabled.
Extension functions support
Java extension functions do work properly only when:
-
Secure-processing is disabled
-
Functions are defined in a separate jar
-
Functions are augmented during native build phase. For example, they can be registered for reflection:
@RegisterForReflection(targets = { my.Functions.class })
public class FunctionsConfiguration {
} | In native mode, the content of the XSLT source URIs is parsed and compiled into Java classes at build time. These Java classes are the only source of XSLT information at runtime. The XSLT source files may not be included in the application archive at all. |
| Configuration property | Type | Default |
|---|---|---|
A comma separated list of templates to compile at build time in native mode. | List of | |
The package name for the generated classes. |
|
|
TransformerFactory features. |
|
Configuration property fixed at build time. All other configuration properties are overridable at runtime.