cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Pötz <>
Subject Re: [COCOON3] XSLTTransformer optimization and reusability
Date Tue, 21 Oct 2008 23:27:36 GMT
Simone Tripodi wrote:
> Hi Reinhard/everybody,
> I would like to argue with you some simple point about the
> org.apache.cocoon.pipeline.component.sax.XSLTTransformer, sharing
> ideas and collecting feedbacks.
> Note: my attention is focused more just on the basic pipeline API use,
> the test case (mine!!!) is the case where a developer is programming
> an application based only on the pipeline - eventually the optional
> components; by the way, what I'm going to expose doesn't want to be
> incompatible with the Sitemap, etc.
> 1) Optimization: *every time* the XSLTTransformer#setXMLConsumer
> method is called, the XSLT is parsed reading the URL source and used
> to create the javax.xml.transform.sax.TransformerHandler: to be more
> clear
> [...]
> XSLTTransformer xsltTransformer = new
> XSLTTransformer(getClass().getResource("myXSLT.xsl"));
> Pipeline pipeline1 = new NonCachingPipeline();
> pipeline1.addComponent(new StringGenerator("<x><y/></x>"));
> pipeline1.addComponent(xsltTransformer);
> pipeline1.addComponent(new XMLSerializer());
> pipeline1.setup(System.out);
> pipeline1.execute();
> Pipeline pipeline2 = new NonCachingPipeline();
> pipeline2.addComponent(new StringGenerator("<z><w/></z>"));
> pipeline2.addComponent(xsltTransformer);  <==========================
> the URL pointed by getClass().getResource("myXSLT.xsl") will be parsed
> again!!!
> pipeline2.addComponent(new XMLSerializer());
> pipeline2.setup(System.out);
> pipeline2.execute();
> I'm sure we can do, even if small, a nice optimization's step,
> creating just once a javax.xml.transform.Templates (it have to be a
> Class' field) when the constructors or the
> XSLTTransformer#setConfiguration methods are called, then when the
> XSLTTransformer#setXMLConsumer method will be invoked the
> javax.xml.transform.sax.TransformerHandler can be created just
> invoking
> In my mind makes more sense reading the XSLT once, an
> org.apache.cocoon.pipeline.component.sax.XSLTTransformer instance
> should be reusable and it shouldn't read the same XSLT each time it
> has to perform a transformation. Please correct me if I'm wrong!

no makes sense! See - this is the
XSLTProcessorImpl that is used by Cocoon 2.x. It uses the Excalibur
store to avoid the recreation of TransformerHandler objects.

As a quick solution we can of course store the transformer handler
objects in a static hashmap, but in the future we should introduce
stores in Cocoon 3 too.

> 2) Reusability: this point is, in some way, correlated to previous,
> but the focus is on the missing
> XSLTTransformer#setParameters(Map<String, Object> parameters) method.
> At this time I can't reuse the same transformer whit different
> parameters because they can be set only by the constructor or by
> XSLTTransformer#setConfiguration method, but as we already know this
> method has much more sense to be used in the Sitemap...

no objections, go ahead!

> 3) Xalan's XSLTC compatibility: now the XSLTTransformer is not
> compatible with XSLTC because we don't have any way to pass attributes
> to the internal javax.xml.transform.TransformerFactory used to create
> the javax.xml.transform.sax.TransformerHandler. IMHO using the XSLTC
> is very useful in cases where the Transformation is really hard to
> perform! For instance, last week, using the Optimus' XSLT
> ( through XSLTC I saved up about 4
> seconds (!!!) in performing a single transformation, and that sounds
> GREAT!!!

no objections with that either

> Ok I finish here, I don't want you get bored :)

no, not at all - please keep up your great work.

> Please let me know and give me feedbacks, if you agree I'll open the
> Issues and I'm able to provide the needed patches.


I'm sorry for my rather long response times (e.g. your
XIncludeTransformer stuff) but I'm very busy ATM. The
XIncludeTransformer will take me some time to review because I haven't
used it so far with Cocoon 2.x and I have to get familiar with the
XInclude and XPointer specs (at least to some extend).

Reinhard Pötz                           Managing Director, {Indoqa} GmbH

Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member        

View raw message