You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by Stefano Mazzocchi <st...@apache.org> on 2002/04/10 02:19:26 UTC
Closer to get XSLTC working with Cocoon
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Re: Closer to get XSLTC working with Cocoon
Posted by Tom Amiro <To...@Sun.COM>.
Stefano,
Thanks for the detailed report. I'm opening up a bug on it,
so it will get some immediate attention.
Tom
Stefano Mazzocchi wrote:
>
> 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.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
--
Tom Amiro -- SQA Engineer
Sun XML Technology Development
voice: 781-442-0589 Fax: 781-442-1437
eMail: tom.amiro@.sun.com