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
