You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Simone Tripodi <si...@gmail.com> on 2008/10/21 09:57:43 UTC
[COCOON3] XSLTTransformer optimization and reusability
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
http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/transform/sax/SAXTransformerFactory.html#newTransformerHandler(javax.xml.transform.Templates)
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!
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...
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
(http://microformatique.com/optimus/) through XSLTC I saved up about 4
seconds (!!!) in performing a single transformation, and that sounds
GREAT!!!
Ok I finish here, I don't want you get bored :)
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.
Have a nice day, best regards!
Yours,
Simone
--
My LinkedIn profile: http://www.linkedin.com/in/simonetripodi
My GoogleCode profile: http://code.google.com/u/simone.tripodi/
My Picasa: http://picasaweb.google.com/simone.tripodi/
My Tube: http://www.youtube.com/user/stripodi
My Del.icio.us: http://del.icio.us/simone.tripodi
Re: [COCOON3] XSLTTransformer optimization and reusability
Posted by Sylvain Wallez <sy...@apache.org>.
Simone Tripodi wrote:
> Hi Reinhard,
> I'm sorry I was not very clear, as "reloader" I mean a sort of XSLT
> watchdog that reload it when it's changed - it's a feature already
> present in oldest Cocoon's version, Sylvain spoke about it in the Jira
> issue
>
There are two ways you can consider to reload stylesheets: check if it's
up to date when it is used, and reload if necessary, or have a
background watchdog that triggers reload.
The first solution is the simplest one to implement, but has two drawbacks:
- the first user request that uses the modified stylesheet pays the cost
of reloading. Probably not an issue in production systems though, since
XSLTs are not supposed to change often and are usually fast to load.
- on a busy system, it puts a high load on the filesystem to check if
the file has changed. This is solved by ensuring the file is checked
only once for a given period of time (e.g. 1 second) regardless of the
number of uses of the stylesheet that happen during this period. This is
achieved by using a DelayedValidity object that wraps the actual source
validity.
Sylvain
[1]
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-core/src/main/java/org/apache/cocoon/components/source/impl/validity/DelayedValidity.java
--
Sylvain Wallez - http://bluxte.net
Re: [COCOON3] XSLTTransformer optimization and reusability
Posted by Simone Tripodi <si...@gmail.com>.
Hi Reinhard,
I'm sorry I was not very clear, as "reloader" I mean a sort of XSLT
watchdog that reload it when it's changed - it's a feature already
present in oldest Cocoon's version, Sylvain spoke about it in the Jira
issue
https://issues.apache.org/jira/browse/COCOON3-6?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641831#action_12641831
Best Regards, alles gute!
Simone
2008/10/24 Reinhard Pötz <re...@apache.org>:
> Simone Tripodi wrote:
>> Hi Reinhard,
>>
>>>> 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 http://tinyurl.com/5hxbjp - 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.
>>
>> As Sylvain and you suggested, I took a look on
>>
>> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-components/src/main/java/org/apache/cocoon/transformation/XSLTTransformer.java
>>
>> This trasformer, as reported in the Javadoc, is an adaptation of
>> Excalibur's XSLTProcessor. As you wrote, one of the cocoon3-pipeline's
>> main scopes is limit to 0 the dependencies (just the logging library),
>> so I propose you 2 alternatives:
>>
>> 1) include dependencies where necessary;
>>
>> or
>>
>> 2) in the cocoon-pipeline, define a set of interfaces to manage XSLT's
>> stores and reloaders, then include in the cocoon-pipeline simple basic
>> implementations (adapters of HashMap for stores, Threads for
>> reloaders), and include different implementations in cocoon-optional
>> (adapters of Excalibur store for stores, Quartz
>> http://www.opensymphony.com/quartz/ job for reloaders).
>
> What do you mean by 'reloaders' in this context?
>
> --
> Reinhard Pötz Managing Director, {Indoqa} GmbH
> http://www.indoqa.com/en/people/reinhard.poetz/
>
> Member of the Apache Software Foundation
> Apache Cocoon Committer, PMC member reinhard@apache.org
> ________________________________________________________________________
>
--
My LinkedIn profile: http://www.linkedin.com/in/simonetripodi
My GoogleCode profile: http://code.google.com/u/simone.tripodi/
My Picasa: http://picasaweb.google.com/simone.tripodi/
My Tube: http://www.youtube.com/user/stripodi
My Del.icio.us: http://del.icio.us/simone.tripodi
Re: [COCOON3] XSLTTransformer optimization and reusability
Posted by Reinhard Pötz <re...@apache.org>.
Simone Tripodi wrote:
> Hi Reinhard,
>
>>> 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 http://tinyurl.com/5hxbjp - 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.
>
> As Sylvain and you suggested, I took a look on
>
> http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-components/src/main/java/org/apache/cocoon/transformation/XSLTTransformer.java
>
> This trasformer, as reported in the Javadoc, is an adaptation of
> Excalibur's XSLTProcessor. As you wrote, one of the cocoon3-pipeline's
> main scopes is limit to 0 the dependencies (just the logging library),
> so I propose you 2 alternatives:
>
> 1) include dependencies where necessary;
>
> or
>
> 2) in the cocoon-pipeline, define a set of interfaces to manage XSLT's
> stores and reloaders, then include in the cocoon-pipeline simple basic
> implementations (adapters of HashMap for stores, Threads for
> reloaders), and include different implementations in cocoon-optional
> (adapters of Excalibur store for stores, Quartz
> http://www.opensymphony.com/quartz/ job for reloaders).
What do you mean by 'reloaders' in this context?
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________
Re: [COCOON3] XSLTTransformer optimization and reusability
Posted by Simone Tripodi <si...@gmail.com>.
Hi Reinhard,
>> 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 http://tinyurl.com/5hxbjp - 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.
As Sylvain and you suggested, I took a look on
http://svn.apache.org/repos/asf/cocoon/trunk/core/cocoon-pipeline/cocoon-pipeline-components/src/main/java/org/apache/cocoon/transformation/XSLTTransformer.java
This trasformer, as reported in the Javadoc, is an adaptation of
Excalibur's XSLTProcessor. As you wrote, one of the cocoon3-pipeline's
main scopes is limit to 0 the dependencies (just the logging library),
so I propose you 2 alternatives:
1) include dependencies where necessary;
or
2) in the cocoon-pipeline, define a set of interfaces to manage XSLT's
stores and reloaders, then include in the cocoon-pipeline simple basic
implementations (adapters of HashMap for stores, Threads for
reloaders), and include different implementations in cocoon-optional
(adapters of Excalibur store for stores, Quartz
http://www.opensymphony.com/quartz/ job for reloaders).
We could include also a strategy similar to the commons-dicovery
(commons.apache.org/discovery) to discover what kind of Store/Reloader
have to be used.
What do you think about it?
Best regards,
Simone
Re: [COCOON3] XSLTTransformer optimization and reusability
Posted by Simone Tripodi <si...@gmail.com>.
Hi Reinhard!!!
thank you for your reply!!!
I'll proceed working on all these small issues - and I'll provide the
patches ASAP :)
> 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).
Don't worry, I already though you're busy, you don't have anything to
be sorry :)
Take care, best regards,
Simone
>
> --
> Reinhard Pötz Managing Director, {Indoqa} GmbH
> http://www.indoqa.com/en/people/reinhard.poetz/
>
> Member of the Apache Software Foundation
> Apache Cocoon Committer, PMC member reinhard@apache.org
> ________________________________________________________________________
>
--
My LinkedIn profile: http://www.linkedin.com/in/simonetripodi
My GoogleCode profile: http://code.google.com/u/simone.tripodi/
My Picasa: http://picasaweb.google.com/simone.tripodi/
My Tube: http://www.youtube.com/user/stripodi
My Del.icio.us: http://del.icio.us/simone.tripodi
Re: [COCOON3] XSLTTransformer optimization and reusability
Posted by Reinhard Pötz <re...@apache.org>.
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
>
> http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/transform/sax/SAXTransformerFactory.html#newTransformerHandler(javax.xml.transform.Templates)
>
> 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 http://tinyurl.com/5hxbjp - 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
> (http://microformatique.com/optimus/) 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.
great!
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
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member reinhard@apache.org
________________________________________________________________________