Increase XSLT extension test coverage

[zhfeng]

• complete URL (classpath, file, http, ref, bean)
• different outputs (string, bytes, dom, file)
• using xsl:include to include files
• custom XsltUriResolverFactory
• custom URIResolver
• using org.apache.camel.component.xslt.XsltAggregationStrategy
• caching
• Being able to raise errors with xsl:message and messages getting into Exchange.XSLT_ERROR, Exchange.XSLT_FATAL_ERROR, or Exchange.XSLT_WARNING

[zhfeng]

ref and bean URI will generate xslt templates dynamically at runtime. So I think it could not be supported in native mode.

[ppalaga]

ref and bean URI will generate xslt templates dynamically at runtime. So I think it could not be supported in native mode.

Yeah, those cases are harder, but still perhaps doable to some extent, as long as the XSLT stuff is known at build time. Of course, if the user generates XSLT resources dynamically at runtime, it won't work in native mode. But if he only has a @Named singleton bean that he uses in a ref URI, then it could perhaps work with some additional config or a new dedicated annotation, something like @XsltResource("foo/bar.xsl"). Then we could scan for those @XsltResource annotations at build time and simply replace ref:beanName for classpath:foo/bar.xsl. Maybe if we had buildtime routes introspection API even the additional config/annotation would not be needed. I am not sure how much cases we could cover like this and I am not sure at all whether this is worth the effort. Perhaps not at this time, we might have more important things to do.

[zhfeng]

Thanks @ppalaga and I think these URIs such as refand bean should work at JVM mode at least. quarkus.camel.xslt.sources must be used for classpath: to work in native mode but it should work in JVM mode without this config and generate template at runtime dynamically.

[zhfeng]

There is a CAMEL-18266 issue with xslt:bean currently.