James.Strachan wrote: > > On 27/11/2007, Przemyslaw Budzik <[EMAIL PROTECTED]> wrote: >> James, it was problem not with camel-servicemix integration, but with >> xslt >> endpoint. It seems XSLT component has problems with finding xsl file. If >> I >> removed that endpoint it would work. The question is then - if we have >> endpoint like this "xslt:file_name" where it is supposed to be located? I >> mean in that scenario. > > The XSLT component uses the Spring Resource handling. So by default it > looks on the classpath unless you specify a file or HTTP based URL. > > e.g. if you want to use the file system use > > xslt:file://foo/bar.xsl > > otherwise > > xslt:foo.xsl > > will use the classpath. See the Spring documentation... > http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/core/io/DefaultResourceLoader.html > > I've updated the wiki document to make this a bit more clear > http://cwiki.apache.org/CAMEL/xslt.html > > -- > James > ------- > http://macstrac.blogspot.com/ > > Open Source Integration > http://open.iona.com > >
Przemyslaw.Budzik wrote: > > You are basically right, but it didn't work for us (from some wierd > reasons). We firstly created XsltProcessor class doing XSLT transformation > (based on Saxon) what worked perfectly well (but was one-off solution) and > then we managed to inject resolver class to default XSLT component. It > successfully found xslt file however didn't find imported sub-stylesheets. > We had the same problem in servicemix's saxon SE and the solution was > using provided URIResolver. We have idea of injecting XMLConverter using > Spring context to xslt component of Camel which would be our own class > based on Saxon with our resolver. The only problem is that XMLConverter is > not supposed to be a component/bean. Solution is simple: providing a > setter. We can patch your code or derive our own flavor of that component, > but want to avoid that. Could you please commit such small "feature" to > trunk? I mean add setter for that object so that we could take control > over that object? We're getting closer and closer to put our flow to > servicemix-camel :) > James.Strachan wrote: > > :) > > Sure. I was hoping we could use Spring to dependency inject the > XmlConverter. > > I've added a setter on the XsltBuilder and made the XsltComponent use > dependency injection to create a new XsltBuilder instance (so we could > do auto-wiring and stuff). See if that helps you customize the > XmlConverter. We'll happily patch the code to make it easier to > customize resolvers and such like. > Thanks a lot! Yes, it helped and we have a working assembly. However we had to provide kind of workaround for XsltComponent class in order to inject transformerFactory to xmlConverter. Current design gives no chance to control that object. Anyway probably our case may be quite common. I mean we rely on Saxon as an XSLT engine (especially on its functions) and it would be reasonable to provide easy, out-of-the box solution to use such component instead of tweaking xslt component in spring context. -- View this message in context: http://www.nabble.com/Camel%2BSM-question-tf4874073s12049.html#a14022549 Sent from the ServiceMix - User mailing list archive at Nabble.com.
