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 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.
-- 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.
-- 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.
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).
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.
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).
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
