cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simone Tripodi" <>
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 - 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

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;


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 job for reloaders).
We could include also a strategy similar to the commons-dicovery
( to discover what kind of Store/Reloader
have to be used.

What do you think about it?
Best regards,

View raw message