Carsten Ziegeler wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
I wanted to write a mail about this today, funny. My usecase is that I want to
replace Xalan by Saxon.
Am I right that creating a cocoon-xalan module would be the best solution for
this because it would make it possible to exclude it at POM level.
Yes, this is one solution :) Making an own module for both, Xalan and
Saxon, has the advantage that this module would depend on Xalan or Saxon
and then you get these libraries automatically in your project as well.
If it's just a configuration issue, like setting a specific value for a
bean, then we could just provide a property reference. Which means, if
switching from Xalan to Saxon is just changing the name of the factory,
we could just make the factory configurable through a well-defined property.
This would work if we hadn't the "xalan" transformer, wouldn't it?
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?
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.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
