Adam Jenkins schrieb am 20.04.2009 um 14:46:55 (-0700):
>
> I have notice some really odd behavior when using
> org.apache.xpath.NodeSet.
> Then, when I had to collect a range of different nodes to work with
> (kind of like a preprocessing step) I created one directly and added
> nodes to it. They added correctly, however I can no longer use
> xsl:for-each.
> <xsl:variable name="nodebucket"
> select="java:org.apache.xpath.NodeSet.new()"/>
Hi Adam,
this is an interesting case. At this point, the variable is bound and
should never change as far as XSLT is concerned. (Remember, variables
aren't.)
> <!--
> next I have a range of apply-templates that pass the variable
> nodebucket as a parameter, that performs the following at various
> places
>
> <xsl:variable name="tmp" select="java:addNode($nodebucket, .)"/>
You're submitting data that is supposed to be immutable to a series of
changes. Looks suspicious to me.
> this works fine, as is indicated by the logging statement below
> -->
>
> <log:debug message="number of nodes to process {java:size($nodebucket)
> + 1}"/> <!--this prints out the correct value of 33 -->
Really? Surprising. But then, it's a bizarre case.
> <xsl:for-each select="$nodebucket">
> <!--this never executes! -->
And it shouldn't - this *is* an empty node-set!
My theory: The XSLT variable is frozen for the purpose of XSLT
processing, but the underlying data structure continues to be subject
to (undue) manipulation by Java. A case for the experts to comment!
You could also consider posting a small but complete test case that
exposes the problem while being easy to understand.
Best,
Michael Ludwig
