cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject JXPath logicsheet problem found
Date Sat, 14 Dec 2002 07:24:14 GMT
I found the problem with the "prefs" flow sample barfing on the 
registration page.

The problem is definitely a Xalan problem, everything works just fine 
with 2.3.1, but fails on 2.4.1. The issue seems to be with the way the 
JPath logicsheet compiles the XPath expressions referred to in an XSP 
page. This is the relevant code:

   <xsl:key name="JPathExprs" match="jpath:if" use="@test"/>
   <xsl:key name="JPathExprs" match="jpath:when" use="@test"/>
   <xsl:key name="JPathExprs" match="jpath:for-each" use="@select"/>
   <xsl:key name="JPathExprs" match="jpath:value-of" use="@select"/>

and later in the logicsheet we have:

         // Generate the compiled representation of the JXPath
         // expressions used by this page.
           select="(//jpath:if | //jpath:when)
                   [generate-id(.) = generate-id(key('JPathExprs', 
                   | (//jpath:for-each | //jpath:value-of)
                   [generate-id(.) = generate-id(key('JPathExprs', 

which is later translated into a call to:

   <xsl:template name="get-var-name">
     <xsl:param name="expr"/>
     jxpath_<xsl:value-of select="translate($expr, 


This should generate unique variable names for each <jpath:*> element 
in an XSP page. For example if the page refers to:

<jpath:value-of select="firstName"/>

the equivalent compiled code is:

       = jxpathContext.compile("firstName");

Xalan 2.4.1 seems to have problems while trying to generate code for 
more complex XPath expressions like:

     <jpath:when test="check and firstName = ''">

It will silently ignore the instructions above and not generate any 
code which precompiles the XPath expression.

Bummer! I have no idea how to work around this problem. I'll try to 
come up with a simpler testcase, outside of Cocoon that reproduces the 
bug and log it in as a bug in Xalan. In the meantime it would be really 
nice if someone has a good workaround for this problem.

An obvious one is to revert to Xalan 2.3.1, but I'm not sure this is 
something desirable. Any thoughts? Does anyone depend on any special 
features from 2.4.1?


Ovidiu Predescu <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message