Stefano Mazzocchi wrote:
>One day I decided to see what could be done to address the fact that
>server-side XSLT transformations might become a serious performance
>bottleneck for massive use of cocoon.
>
>So I went ahead and did some tests on my machine, these were not
>extensive enough for a published paper, but they were ok to get the
>figures and estimate where the hotspots are.
>
>I discovered, with much surprise, that Xalan XSLTC is 600% faster than
>regular Xalan and 200% faster than MSXML 3.0 which is a native XSLT
>implementation (the tests were run on win2k).
>
>It looks clear that Cocoon would practially solve many of its current
>performance problems simply by making it possible to use Xalan XSLTC
>instead of regular Xalan.
>
> -- o --
>
>My intention is to work with the Xalan community to get those issues
>solved. I'm not interested in working on forked versions which
>opensource faith is not decided.
>
I fully agree with this point of view.
>I fully believe in the power of communities and I strongly believe that
>no single person, no matter how smart and brilliant, can match the power
>of the distributed IQ of a sane and focused open development community.
>
>For this reason, I decided to place my effort in making sure that the
>Cocoon and the Xalan community work together, even if this requires
>changes in both sides.
>
Can you elaborate more on these changes ? Is there any obstacle for
Xalan and Cocoon to collaborate ?
>
>
> -- o --
>
>XSLT is used in three different places in Cocoon:
>
> 1) generation of sitemap source code our of XML descriptor
> 2) generation of XSP source code our of XSP pages
> 3) transformation of generated XML content
>
>1) and 2) are *not* used at runtime, or, if so, their runtime execution
>is done once for page change, which is *very* unfrequent in production
>environments.
>
>3) is our main runtime concern and source of performance problems so
>here is where we should target the use of XSLTC.
>
>In the future, the use of interpreted versions of both sitemap and XSP
>might remove the need to have an XSLT processor in these stages, but for
>now, this is not our main concern.
>
> -- o --
>
>Cocoon implements runtime pipeline transformations using a
>TrAXTransformer. This transformer accepts the following parameters:
>
> use-request-parameters
> use-browser-capabilities-db
> use-session-info
> xslt-processor-role
>
>while the first three are used to indicate the behavior of XSLT param
>expansion, the fourth one is used to identifiy the 'ROLE' of the Avalon
>component that is used to implement the required functionality.
>
>At first, this sounds like a cool thing, but closer inspection finds
>this usage of Avalon patterns *totally* broken.... let's look at the
>code of TrAXTransformer:
>
> child = conf.getChild("xslt-processor-role");
> String xsltRole = child.getValue(XSLTProcessor.ROLE);
>
> try {
> this.xsltProcessor = (XSLTProcessor)
>this.manager.lookup(xsltRole);
> } catch (ComponentException e) {
> throw new ConfigurationException("Cannot load XSLT processor", e);
> }
>
>Now, there is *absolutely* not sense in making the ROLE to be looked up
>configurable, because an Avalon ROLE is a behavioral identification, not
>an instance identification.
>
>In fact, if we implement a different ROLE and try to load it from there,
>it doesn't work because you get a ClassCastException.
>
>What we want here, is *NOT* the ability to define our own ROLE, but a
>way to define the HINT for that ROLE (that is, translated in regular
>java terms: we want to be able to choose the implementing class, not to
>choose a different interface).
>
>So, in short, the above code prevents us from having two different
>implementations of the XSLTProcessor component running in the same
>system and used by the TrAXTransformer.
>
This *was made* to allow several processors simultaneously ! As the
author of this, let me explain why I did it, and how I use it :)
In the developments made in my company, Saxon was chosen a long time ago
as the XSLT processor of choice, mainly because of its better
performance compared to Xalan. So people used Saxon, and also used its
cool-but-proprietaty extensions. At that time we were using Cocoon 1,
and we used Saxon as the default and only XSLT processor.
Then came Cocoon 2. And we had some problems when using Saxon for
sitemap compilation because of some Xalan extensions used in the sitemap
engine (don't remember exactly what).
So I used a pattern I heard of in Avalon-land and that's described by
Berin in the "Choosing the Role's name" paragraph at
http://jakarta.apache.org/avalon/developing/framework.html : if there
are several variations of a same work interface, append "/variant" to
the work interface role.
So here's an extract of our cocoon.xonf :
<xslt-processor logger="root.xslt-processor">
<parameter name="use-store" value="true"/>
<parameter name="transformer-factory"
value="org.apache.xalan.processor.TransformerFactoryImpl"/>
</xslt-processor>
<component role="org.apache.cocoon.components.xslt.XSLTProcessor/SAXON"
class="org.apache.cocoon.components.xslt.XSLTProcessorImpl"
logger="root.saxon">
<parameter name="use-store" value="true"/>
<parameter name="transformer-factory"
value="com.icl.saxon.TransformerFactoryImpl"/>
</component>
Note that the TrAX factory class is specified, allowing a deterministic
choice when service manifest files of several engines are conflicting in
the classpath.
And here's an extract of our sitemap.xmap :
<map:transformer name="xslt"
src="org.apache.cocoon.transformation.TraxTransformer"
pool-max="32" pool-min="16" pool-grow="4"
logger="sitemap.transformer.xslt">
<use-request-parameters>false</use-request-parameters>
<use-browser-capabilities-db>false</use-browser-capabilities-db>
<xslt-processor-role>org.apache.cocoon.components.xslt.XSLTProcessor/SAXON</xslt-processor-role>
</map:transformer>
With the above, Xalan (associated to the "standard" role) is used by the
sitemap engine, and Saxon is used everywhere in the sitemap. We didn't
want to use Xalan in the sitemap, but had we wanted that, we would have
declared another transfomer using the same TraxTransfomer class but with
a different xslt-processor-role, thus being able to use *both* XSLT
engines in the sitemap.
Maybe a better solution would have been to replace the xslt-processor
role by a Selector. But I found this overkill for what seemed to me a
marginal use (most people use Cocoon + Xalan out of the box).
>
> -- o --
>
>Note that, thanks to TrAX, we don't need to implement more than one
>XSLTProcessor implementation, we just have to specify which TrAX factory
>implementation the component must use.
>
>So, our need is:
>
> 1) TrAXTransformer must have a way to access a specific instance of a
>component, not its role.
>
By "instance", do you mean "hint" in a Selector ?
>
> 2) The component manager should be able of associating different
>identifiers to components which have the same ROLE, the same
>implementation class, but have different configurations (which are used
>to indicate what TrAX factory to use).
>
A ComponentSelector allows this.
>If the above two things are implemented, it could be entirely possible
>to have many different XSLT implementation running inside Cocoon and
>handling different parts of the URI space.
>
We already can *today* : I've been using it for many months.
>Ok, now: I think I need some Avalon advice here, Berin? is the Excalibur
>Component Manager already able to do the above? (sorry, i don't have the
>code at hand right now).
>
There was a proposal some time ago on avalon-dev for a new
ComponentManager that would hide Selectors. AFAIR (Berin, correct me if
I'm wrong), this can allow to transparently switch a single component to
a selector : if no hint is given, a default instance is selected (just
as for sitemap components).
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
