camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From weather99 <>
Subject RE: camel xslt 2.0 support
Date Tue, 26 Jun 2012 13:18:17 GMT
I included the xslt file as a resource in my jar and did what you suggested.
I got the same result:  Only the prolog showed up in the converted message.
Thanks for the idea, though.

From: Henrique Viecili [via Camel] []
Sent: Monday, June 25, 2012 9:09 AM
To: Fleishaker, Frank
Subject: Re: camel xslt 2.0 support

I see you are using xsl:file:xsl/my.xsl, you don't need to use *file:*
which may be swallowing the transformerFactoryClass configuration. Try
using *only* xsl:xsl/my.xsl?transaformerFactoryClass

*Henrique Viecili

On Thu, Jun 21, 2012 at 2:45 PM, weather99 <[hidden email]</user/SendEmail.jtp?type=node&node=5715048&i=0>>

> Despite installing servicemix-saxon, and following the instructions on this
> and other threads, I still cannot get xslt 2.0 to work in Servicemix 4.4.1
> or 4.4.2.  The converted message shows up with only the prolog <?xml
> version="1.0" encoding="UTF-8"?>, which indicates an xslt 1.0 conversion
> was
> done.
> I'm using this as part of my route:
> <camel:to
> uri="xslt:file:xsl/my.xsl?transformerFactoryClass=net.sf.saxon.TransformerFactoryImpl"
> />
> I have also tried this same thing via. a bean, with the same result:
> <to uri="xslt:file:xsl/my.xsl?transformerFactory=tFactory" /> <bean
> id="tFactory" class="net.sf.saxon.TransformerFactoryImpl" />
> In order to troubleshoot further, I embedded the entire xslt transformation
> inside a bean, using the saxon9he jar file.  It worked in standalone Camel.
> To make sure I had no external dependencies for the conversion, I built it
> with the extracted classes from the saxon jar.  When I tried to run it in
> Servicemix, i got this result:
> Line #1; Column #473; "xpath-default-namespace" attribute is not allowed on
> the xsl:stylesheet element!
> SystemId Unknown; Line #55; Column #86; Could not find function: upper-case
> This also indicates that only an xslt 1.0 conversion was attempted, since
> the processor doesn't know what to do with these tags.  This is the bean I
> was using:  <bean ref="xslt20" method="map" />
> It appears that in Servicemix, the xalan jar in ./lib/endorsed overrides
> all
> xslt processing no matter what.  I tried removing the xalan-2.7.1.jar from
> that directory.  My route wouldn't start, and I got this message:
> org.springframework.beans.factory.BeanCreationException: Error creating
> bean
> with name 'xslt20' defined in URL
> [bundle://187.0:0/META-INF/spring/beans-0.0.0.xml]: Instantiation of bean
> failed; nested exception is
> javax.xml.transform.TransformerFactoryConfigurationError: Provider
> *org.apache.xalan.processor*.TransformerFactoryImpl not found
> So it seems that it's always looking for xalan no matter what, which is
> only
> an xslt 1.0 processor.
> Please advise as to what I'm doing wrong.  We have a lot invested in xslt
> 2.0 in standalone Camel, and I'm now at a dead-stop trying to deploy it to
> Servicemix.
> Thanks.
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

If you reply to this email, your message will be added to the discussion below:
To unsubscribe from camel xslt 2.0 support, click here<>.

View this message in context:
Sent from the Camel - Users mailing list archive at
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message