Reinhard Poetz wrote: >> Hmm, yes and no :) Our xslt transformer implementation uses an xslt >> processor. So we can define a "static" xalan xslt processor together >> with a "static" xalan xslt transformer. > > And this works because when the processor bean is created by Spring there is > no > need to have Xalan on the classpath. Right? > Hmm, no :) If Xalan would not be on the classpath I guess the xslt processor would fail. But as Xalan is always included in the jdk, it's always available (of course this might be different with different jdks). So, if we provide a "static" xalan xslt processor/xslt transformer combo, Xalan has to be on the classpath. However, we could implement these beans in a way that they don't fail during initialization/configuration if Xalan is not available. They would fail when they're used. But I'm in favour of fail early here.
>> And we can define a "dynamic" xslt processor (configured through >> properties) with an xslt transformer always using this "dynamic" xslt >> processor. > > If it was a Spring bean we could even use the PropertyOverrideConfigurer > instead > of introducing a new property. > > Would it be difficult to convert the TraxProcessor into a Spring bean? As it > hasn't been done yet I guess that there is this or that difficulty involved, > isn't it. The TraxProcessor uses the source resolver to resolve included/imported stuff and to handle xslt changes checks. We could convert the processor to a spring bean and simply referene the source resolver. It shouldn't be that hard. I think I'll have a look at this. Carsten -- Carsten Ziegeler http://www.osoco.org/weblogs/rael/
