Julian Birch wrote:
> > If you do "build clean" and then "build jar" you should get a jar with
> > debugging information.
>
> For reasons I don't understand, the variable information is _still_ being
> stripped out. I'm wondering whether ant switches on optimisation. In any
> event, it's driving me crazy, but isn't really xalan-related. I may end up
> getting a commercial Java package.
Julian --
I use "-Ddebug=on" as a parameter to Ant and everything builds with
debugging symbols just fine.
> All of this said, I do believe the original code should work as it shouldn't
> be necessary to refer to org.apache.* when writing an extension. Looking at
> it, it looks like the issue is that the XPathContext object should allow for
> the pushing of arbitrary org.w3c.dom.traversal.NodeIterator or
> org.w3c.dom.NodeList objects and should sort the interface details out
> itself.
>
> So:
> i) Do people agree that this is a bug? If so, I'll log it.
Well, I agree it's a bug but not with Xalan. I ran into the same thing
when I was tracking down a problem with tracing. The problem is that
some methods that Xalan (or any reasonable user in my opinion) needs are
just missing from the NodeIterator definition. Like clone(). XalanJ
needs to be able to clone() a NodeIterator every once in a while. In
the example that I ran into, XalanJ was tracing a NodeIterator. It
needed to print out all of the nodes in the node-set represented by the
NodeIterator but it couldn't do that without destroying the state of the
NodeIterator since it had to keep calling nextNode() to print all of the
nodes in the node-list. So, the clone() method was added to
ContextNodeList so that NodeIterators could implement the methods that
XalanJ needed that weren't part of the NodeIterator definition. Same
with things like isFresh(). XalanJ just needed to know these things and
there isn't any easy way to get this from a NodeIterator.
> ii) Do people agree that the proposed solution is correct? If so, I'll try
> to implement it and submit the change back to here. (This might take a bit
> longer.)
I'm confused here. If I want to use a NodeIterator to return from a
Xalan extension function, aren't I going to have to implement clone(),
for example, so that my NodeIterator can be used while tracing? If I
use your wrapper class, the clone() method throws an exception which is
not what I want. And what about reset(). You're just ignoring it but
sometimes XalanJ needs to reset the NodeIterator to its initial state.
I'm afraid I'm confused about how your wrapper class solves this
problem.
>
> As a side note, I don't believe I should have needed the getNodeList
> function, it should have been possible to just call new, but this is small
> potatoes.
I agree with you about getNodeList(). If you just call new(), does this
cause a problem? If so, what is the problem?
Gary
