Vadim's Notes

Using XT with Cocoon (For real!)

Ok, so if you read the previous piece on XT integration, situation was seeming grim... In desperation, I was trolling the web and found out that just couple of days ago new release of XT is out, XT Version 20051012 with, quote:

more complete JAXP API support

Excellent! Let's give it a spin! So, steps are:

• Download, unzip, patch TransformerFactoryImpl (same issue as before)
• Set org.xml.sax.parser environment variable (same issue)
• Fire it up... Bang! NullPointerException.
• (To make long story short) Patch it up... Wow! It worked!

After patching up attributes handling in MultiNamespaceResult and ResultBase, of com.jclark.xsl.sax2 package, it really worked.

So now we can finally get to performance testing. On my setup, which I preserved from previous testing, it gave great results! Numbers showed that it is as good as XSLTC and in one scenario even faster! On a memory usage front, it was standing consiistently higher than XSLTC, but significantly lower than the usual suspects.

All in all, even if it requires namespace-prefixes turned on, XT is getting back into the play, and has good chance to change my preference for default XSLT processor. Great work!

PS Those who want to try out XT, mine patched version is here: xt20051012m.zip

Using XT with Cocoon

As some of you know, recently over at Cocoon GetTogether 2005, we had a presentation about XSLT processors performance in Cocoon environment. Results for Xalan, Saxon, XSLTC were presented. Soon after that Upayavira mentioned that XT is out of hibernation and gets some maintenance (apparently by XMLEcho / Palomar guys), and he suggested to run tests against XT as well.

It's easier said than done, as people say... It all started out just peachy: XT Release 20050823 promised SAX2 and JAXP, so may be it has TrAX as well, and it did not take me long to get name of transformer factory:

    com.jclark.xsl.trax.TransformerFactoryImpl 

Excellent. I drop xt jar into WEB-INF/lib, start up servlet engine... On the first request it blows with exception:

    no such prefix: xsl 

It happened when it was trying to parse <xsl:stylesheet> element (that's when I understood it won't be easy...). Culprit of lost namespaces was the way how namespaces were processed:

    public void startPrefixMapping(String prefix, String uri)
    {
        // I think we'll just extract 'em from the attributes
    }

Which gave a clue that it might work with name space prefixes enabled:

<xml-parser class="org.apache.excalibur.xml.impl.JaxpParser">
  ...
  <parameter name="namespace-prefixes" value="true"/>
  ...
</xml-parser>

And miracle happened! It did worked! Till it hit an NPE telling me that some XMLReader was not initialized somewhere within it guts... Patched it in com.jclark.xsl.trax.TransformerFactoryImpl:

public TemplatesHandler newTemplatesHandler()
    throws TransformerConfigurationException
{
    try {
        XMLReader reader = newDefaultReader();
        reader.setFeature("http://xml.org/sax/features/namespaces", true);
        reader.setFeature("http://xml.org/sax/features/namespace-prefixes", true);

        return new TemplatesHandlerImpl(this, new XMLProcessorImpl(reader));
    } catch(Exception e) {
        throw toConfigException(e);
    }
}

Failed with NPE. Now I found out it is not fully yet integrated with Jaxp... It could not find SAXParser. Here we go:

    set JAVA_OPTS=
        -Dorg.xml.sax.parser=org.apache.xerces.parsers.SAXParser

Moving further... Failed with TransformerConfigurationException:

Caused by: javax.xml.transform.TransformerConfigurationException:
    newTransformerHandler(Templates templates) not yet implemented
	at com.jclark.xsl.trax.TransformerFactoryImpl.
            newTransformerHandler(TransformerFactoryImpl.java:404)

Showstopper. No TrAX for us.

To be continued...