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]
________________________________________________________________________
