...
There is a test case along with its Spring XML if you want a concrete example.
Using xsl:include
Camel 2.2 or older
If you use xsl:include in your XSL files then in Camel 2.2 or older it uses the default javax.xml.transform.URIResolver
which means it can only lookup files from file system, and its does that relative from the JVM starting folder.
For example this include:
Code Block | ||||
---|---|---|---|---|
| ||||
<xsl:include href="staff_template.xsl"/>
|
Will lookup the staff_tempkalte.xsl
file from the starting folder where the application was started.
Camel 2.3 or newer
Now Camel provides its own implementation of URIResolver
which allows Camel to load included files from the classpath and more intelligent than before.
For example this include:
Code Block | ||||
---|---|---|---|---|
| ||||
<xsl:include href="staff_template.xsl"/>
|
Will now be located relative from the starting endpoint, which for example could be:
Code Block |
---|
.to("xslt:org/apache/camel/component/xslt/staff_include_relative.xsl")
|
Which means Camel will locate the file in the classpath as org/apache/camel/component/xslt/staff_template.xsl
.
This allows you to use xsl include and have xsl files located in the same folder such as we do in the example org/apache/camel/component/xslt
.
You can use the following two prefixes classpath:
or file:
to instruct Camel to look either in classpath or file system. If you omit the prefix then Camel uses the prefix from the endpoint configuration. If that neither has one, then classpath is assumed.
You can also refer back in the paths such as
Code Block |
---|
<xsl:include href="../staff_other_template.xsl"/>
|
Which then will resolve the xsl file under org/apache/camel/component
.
Notes on using XSTL and Java Versions
...