I'm about to check in org.apache.xpath.operations.Variable.java that has a
rather nasty hack. The issue is that extensions are building their xpaths
on the fly, so they don't really have a chance to fix up their index lookup
for the variable stack (this problem caught me a bit by surprise). The
variable stack itself no longer has any qname information... it's a
straight index lookup to the variable value. In order to work around this
problem in the short term, I test whether fixupVariables has been called,
and, if it hasn't, I take the current prefixResolver, *which must be set to
the extension element* (it wasn't in the Redirect extension), test if it is
a ElemTemplateElement (bad because we're not supposed to be coupled with
the xalan package in xpath), and look at the previous sibling and ancestor
previous siblings for a ElemVariable. For each ElemVariable, I can then
compare the qname, and, if a match, get the index from that element. Right
now it doesn't do anything special for global variables, and so errors can
occur in this case if you have imports and includes and the like. The hack
is good enough right now to get fop codegen to work correctly. I'll do
some more work on this next week, or someone else can, and I'll try and
figure out a way to do this without the visibility to xalan.
Anyway, I wanted to make sure I properly flagged the hack.
-scott
