Re: [COCOON3] XSLTTransformer optimization and reusability
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
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 <[EMAIL PROTECTED]>:
> 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 [EMAIL PROTECTED]
>
>
--
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
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 [EMAIL PROTECTED]
Re: [COCOON3] XSLTTransformer optimization and reusability
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
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 [EMAIL PROTECTED]
>
>
--
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
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(""));
> pipeline1.addComponent(xsltTransformer);
> pipeline1.addComponent(new XMLSerializer());
> pipeline1.setup(System.out);
> pipeline1.execute();
>
> Pipeline pipeline2 = new NonCachingPipeline();
> pipeline2.addComponent(new StringGenerator(""));
> 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 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 [EMAIL PROTECTED]
