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}"/> </c:import> <x:forEach select="$sample/sample/link"> <c:set var="link"> <x:out select="@href"/> </c:set> <c:import url="${link}" varReader="r2"> <x:parse var="sample2" doc="${r2}"/> </c:import> <!-- *** 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"/> </x:forEach> ====================== sample.xml: ====================== <sample> <link href="sample2.xml"/> </sample> ====================== sample2.xml: ====================== <sample2> <text>this is just a test!</text> </sample2> ====================== I'm using JSTL 1.1, Jakarta Taglib Standard 1.1.0, Tomcat 5.0.25 (same problem on both linux and windows) flavio
Confirmed. 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.
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.
Created attachment 19258 [details] Manual Test JSP
Created attachment 19259 [details] XML for Test JSP
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.
Created attachment 19295 [details] Cactus test for this issue
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.
*** Bug 41481 has been marked as a duplicate of this bug. ***