cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: New Features for the spring configurator
Date Mon, 26 Feb 2007 12:32:46 GMT
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 Ziegeler

View raw message