Bug 30068 - Wrong behaviour of x:out inside x:forEach
Summary: Wrong behaviour of x:out inside x:forEach
Alias: None
Product: Taglibs
Classification: Unclassified
Component: Standard Taglib (show other bugs)
Version: 1.1.0
Hardware: All All
: P3 normal with 3 votes (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2004-07-13 10:11 UTC by Flavio
Modified: 2007-01-29 08:29 UTC (History)
1 user (show)

Manual Test JSP (860 bytes, text/plain)
2006-12-13 13:54 UTC, Henri Yandell
XML for Test JSP (101 bytes, text/plain)
2006-12-13 13:54 UTC, Henri Yandell
Patch to fix this issue (660 bytes, patch)
2006-12-13 13:56 UTC, Henri Yandell
Details | Diff
Cactus test for this issue (3.42 KB, patch)
2006-12-20 17:10 UTC, Henri Yandell
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Flavio 2004-07-13 10:11:38 UTC
hi all,
inside a x:forEach loop, i put an x:out that evaluates an XPath expression on a
document which is not same of the x:forEach.
The x:out seems to behave strangely. Take a look at following JSP:


<%@ taglib prefix="x" uri="http://java.sun.com/jsp/jstl/xml" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<c:import url="sample.xml" varReader="r">
  <x:parse var="sample" doc="${r}"/>
<x:forEach select="$sample/sample/link">
  <c:set var="link">
    <x:out select="@href"/>

  <c:import url="${link}" varReader="r2">
    <x:parse var="sample2" doc="${r2}"/>

  <!-- *** this does not work *** -->
  <x:out select="$sample2/sample2/text"/>

  <!-- this does work, but i think it is not correct -->
  <x:out select="$sample2/text"/>



  <link href="sample2.xml"/>


  <text>this is just a test!</text>


I'm using JSTL 1.1, Jakarta Taglib Standard 1.1.0, Tomcat 5.0.25 (same problem
on both linux and windows)

Comment 1 Henri Yandell 2006-12-06 18:01:51 UTC

If you do the same code outside the x:forEach, it the first x:out succeeds and
the second x:out fails, as expected. Switching away from the reader and to a
string doesn't get rid of the bug. 

Debugging... all I've found out so far is that when the x:out is in the forEach,
the $sample2 at the front makes its way down into the guts. If I add a hack to
remove '$sample2' from things though, they're not magically fixed.

The other difference is that the ContextNode is CNode: [link: null] in the
forEach case and CNode: [#document: null] in the simple case. That seems very
likely to be tied to the bug - without really knowing what they are, it seems
that a different xml document should have a different context node.
Comment 2 Henri Yandell 2006-12-13 13:44:05 UTC
Digging more. The ContextNode is a modified version of the Node parameter passed
in - it represents '.'. It's document specific - so should be tied to the xml
document in question and not be shared.

However...this doesn't explain why the alternative actually does work.

Comment 3 Henri Yandell 2006-12-13 13:54:36 UTC
Created attachment 19258 [details]
Manual Test JSP
Comment 4 Henri Yandell 2006-12-13 13:54:52 UTC
Created attachment 19259 [details]
XML for Test JSP
Comment 5 Henri Yandell 2006-12-13 13:56:14 UTC
Created attachment 19260 [details]
Patch to fix this issue

This looks like it fixes the problem. If the expression starts with a $...,
then re-evaluate rather than returning the current node.
Comment 6 Henri Yandell 2006-12-20 17:10:12 UTC
Created attachment 19295 [details]
Cactus test for this issue
Comment 7 Henri Yandell 2006-12-20 17:12:30 UTC
svn ci -m "Applying cactus test and patch for issue #30068"

Sending        src/org/apache/taglibs/standard/tag/common/xml/XPathUtil.java
Adding         test/org/apache/taglibs/standard/tag/el/xml
Adding         test/org/apache/taglibs/standard/tag/el/xml/Test30068.java
Adding         test/web/org/apache/taglibs/standard/tag/el/xml
Adding         test/web/org/apache/taglibs/standard/tag/el/xml/Test30068.jsp
Adding         test/web/org/apache/taglibs/standard/tag/el/xml/Test30068.xml
Transmitting file data ....
Committed revision 489238.
Comment 8 S 2007-01-29 08:29:19 UTC
*** Bug 41481 has been marked as a duplicate of this bug. ***