cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simone Tripodi" <simone.trip...@gmail.com>
Subject Re: [COCOON3] XSLTTransformer optimization and reusability
Date Fri, 24 Oct 2008 08:59:33 GMT
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

Mime
View raw message