Hi,
I'm getting closer to have XSLTC running with Cocoon.
First of all, Cocoon had a couple of problems with its internals that I
fixed. These had nothing to do with Xalan at all but might have
prevented smooth operation under some circumstances.
Second, Cocoon TraxTransformer wasn't calling setSystemId() on the
Templates, resulting in XSLTC associating the default translet name
'GregorSamsa' to all of its templates.
This was probably the reason of all those VerifyErrors that we were
getting, expecially on pipelines with multiple cascaded stylesheets.
This was fixed by adding the setSystemId() call to the TraxTransformer.
Xalan operation wasn't disturbed by this (ASAIK)
At this point, I was able to run XSLTC inside Cocoon pipelines (the
Cocoon internals were left to Xalan since XSLTC has problems with XSLT
extensions but we don't really care to support XSLTC for Cocoon
internals, mainly XSP code generation which is not a runtime critical
operation)
A few problems started to appear:
1) in XSLTC.java, the setClassname() method adapts the SystemID to a
valid classname. Later on, in TemplatesImpl.java, the classname is
checked to see if the Templates name matches the classname, but the
string is not java-adapted anymore.
So, if you have a stylesheet called "file:///blah.xsl", the classname
becomes "blah", but the template name becomes "blah.xsl" resulting in an
exception being thrown since the templates can't find the translet for
this name collision.
My fix was to change line 136 of TemplatesHandlerImpl.java from
if (_systemId != null) transletName = Util.basename(_systemId);
to
if (_systemId != null) transletName = Util.toJavaName(_systemId);
[I'm sure there are more elegant ways to solve the issues here, but I'm
just concerned on getting it to run at this moment]
This solved the previous issue but created another one:
2) shown by this partial stacktrace
java.lang.NullPointerException
at
org.apache.xalan.transformer.SerializerSwitcher.switchSerializerIfHTML(SerializerSwitcher.java:193)
at
org.apache.xalan.transformer.TransformerIdentityImpl.startElement(TransformerIdentityImpl.java:988)
at
org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:130)
at
org.apache.cocoon.serialization.AbstractTextSerializer$NamespaceAsAttributes.startElement(AbstractTextSerializer.java:469)
at
org.apache.cocoon.xml.AbstractXMLPipe.startElement(AbstractXMLPipe.java:130)
at
org.apache.xalan.xsltc.runtime.TextOutput.closeStartTag(TextOutput.java:268)
at
org.apache.xalan.xsltc.runtime.TextOutput.startElement(TextOutput.java:468)
at
file__C__Apache_Tomcat_webapps_cocoon_stylesheets_simple_samples2html_xsl.applyTemplates()
at
file__C__Apache_Tomcat_webapps_cocoon_stylesheets_simple_samples2html_xsl.transform()
at
org.apache.xalan.xsltc.runtime.AbstractTranslet.transform(AbstractTranslet.java:535)
....
looking into the NPE-generating code below:
if (((null == ns) || (ns.length() == 0))
&& localName.equalsIgnoreCase("html"))
it seems that a SAX event with a null "localName" was passed thru the
pipeline. Since the problem goes away if Xalan is used, I think this
might be a problem in the "apply-templates" implementation of the
Translets.
Interesting enough, this doesn't happen in the main Cocoon page, but
only in the /welcome page so XSLTC is partially working.
But this is not enough, errors start to become *really* creative:
3) if I move on to the /documents/ section of the Cocoon samples I get:
java.lang.VerifyError: (class:
file__C__Apache_Tomcat_webapps_cocoon_documentation_stylesheets_book2menu_xsl,
method: applyTemplates signature:
(Lorg/apache/xalan/xsltc/DOM;Lorg/apache/xalan/xsltc/NodeIterator;Lorg/apache/xalan/xsltc/TransletOutputHandler;)V)
Unable to pop opera ,@ èÞR P1@ ?1@ D5@ Üí
at java.lang.Class.newInstance0(Native Method)
at java.lang.Class.newInstance(Class.java:237)
at
org.apache.xalan.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:234)
at
org.apache.xalan.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:259)
at
org.apache.xalan.xsltc.trax.TransformerFactoryImpl.newTransformerHandler(TransformerFactoryImpl.java:579)
at
org.apache.cocoon.components.xslt.XSLTProcessorImpl.getTransformerHandler(XSLTProcessorImpl.java:248)
Sounds like Gregor Samsa wants to sing or something :)
Don't ask me what the heck this means, but it still seems to be related
to the ApplyTemplates part of the translet.
Anyway, enough for now.
Please help :)
--
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]
