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