cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Russell <p...@luminas.co.uk>
Subject [C2] [BUG] Problems with attributes in XSP (suspected Xalan2 bug with namespace-uri)
Date Sat, 25 Nov 2000 15:31:38 GMT
Hi all,

Just been using XSP with C2, and have come across an interesting
(showstopper of a) 'feature'. The following XSP page compiles
and executes fine:

<?xml version="1.0" encoding="ISO-8859-1"?>

<xsp:page
        language="java"
        xmlns:xsp="http://apache.org/xsp"
        xmlns:xsp-request="http://apache.org/xsp/request"
        xmlns:xsp-response="http://apache.org/xsp/response"
        xmlns:log="http://apache.org/xsp/log"
        xmlns:page="http://xmlns.luminas.co.uk/2000/core/page"
>
        <page:page>
                <page:content>
                </page:content>
        </page:page>
</xsp:page>

However, the following XSP page (identical, but with one
attribute in the page tag):

<xsp:page
        language="java"
        xmlns:xsp="http://apache.org/xsp"
        xmlns:xsp-request="http://apache.org/xsp/request"
        xmlns:xsp-response="http://apache.org/xsp/response"
        xmlns:log="http://apache.org/xsp/log"
        xmlns:page="http://xmlns.luminas.co.uk/2000/core/page"
>
        <page:page title="Welcome to Luminas">
                <page:content>
                </page:content>
        </page:page>
</xsp:page>

yeilds the following stack trace on tomcat's standard out/err:

org.apache.cocoon.ProcessingException: Error in XPath
org.apache.cocoon.ProcessingException: Error in XPath
        at org.apache.cocoon.generation.ServerPagesGenerator.generate(ServerPagesGenerator.java:129)
        at org.apache.cocoon.sitemap.ResourcePipeline.process(ResourcePipeline.java:201)
        at _home._paulr._work._cvs._luminas._www_luminas_co_uk._site._webapp._sitemap_xmap.process(_sitemap_xmap.java:642)
        at org.apache.cocoon.sitemap.Handler.process(Handler.java:132)
        at org.apache.cocoon.sitemap.Manager.invoke(Manager.java:87)
        at org.apache.cocoon.Cocoon.process(Cocoon.java:239)
        at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:215)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:387)
        at org.apache.tomcat.core.Handler.service(Handler.java:263)
        at org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:371)
        at org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:786)
        at org.apache.tomcat.core.ContextManager.service(ContextManager.java:732)
        at org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpConnectionHandler.java:210)
        at org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:407)
        at org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
        at java.lang.Thread.run(Thread.java:484)

The reason for this *appears* to be in the following section
of the xsp.xsl logicsheet:

  <xsl:template match="@*">
    xspAttr.addAttribute(
      "<xsl:value-of select="namespace-uri(.)"/>",
      "<xsl:value-of select="local-name(.)"/>",
      "<xsl:value-of select="name(.)"/>",
      "CDATA",
      "<xsl:value-of select="."/>"
    );
  </xsl:template>

Commenting out the <value-of select="namespace-uri(.)"/> fixes
the stack trace, but obviously screws the namespace handling up.

Can anyone reproduce this behaviour?

I suspect it's a bug in Xalan2, but I can't get the latest CVS
of xalan2 to work with cocoon at all at the moment, so it's
kinda hard to check? Scott? Any thoughts mate?


Paul

-- 
Paul Russell                               <paul@luminas.co.uk>
Technical Director,                   http://www.luminas.co.uk
Luminas Ltd.

Mime
View raw message