David,
Thank you for responding as I always await your expert and concise
advice on
Xalan-C++.
A bit of XML which causes the problem might be:
<casperAPI><trigger><oneMoreElement/></trigger></casperAPI>. And note that no
<?xml...> PI precedes this.
After parsing the above string with the parserLiaison (see
SimpleXPathAPI for
the details), I can successfully use calls like
getDocumentElement()->getNodeName() to get strings such as <casperAPI> and so
I feel somewhat confident that the XalanDocument that I pass to
XPathEvaluator::selectSingleNode and selectNodeList is well-formed.
As for calling XPath::executeMore(), O, good grief! I wouldn't dream of
it.
I've simply traced through the Xalan source code to try to learn where
NodeRefList::operator= might be getting passed an invalid rhs from an
XObjectPtr.
Because I can implement the steps of selectNodeList in my code, without
error, up to the point of the line "result = (theResult->nodeset()); and
because the gdb of the core reports that the fault occurs in the
NodeRefList::operator= routine, and because if I add that same attempt to
call the nodeset() method of the target XObject the code then similarly
sigsegv's, I am rather confident that something about "theResult" is
unexpected. As this is down inside Xalan internal code, I would agree that it
is at least something which the Xalan code should guard against. However, I
will not be surprised if I learn that the reason this is occuring is due to
out-of-scoping issue or improper initialization issue which is miscoded by me
earlier in the ultimate parent object's lifetime.
As for parseSource, yes, it is trivial, isn't it? And pleasantly so. I went
ahead and recoded the xml string parsers to use that approach and it all
works nicely. So, I can get rid of all the parserLiaison stuff which isn't
necessary (for this use case anyway.)
I will strive to get a test case and enter a jira bug...
On Thursday 16 June 2005 12:38 pm, [EMAIL PROTECTED] wrote:
> > No, I can't share those because they are highly proprietary. But, they
>
> are
>
> > actually irrelevant to conceptual work to be done. Which I can discuss.
>
> But surely you can come up with a trivial test case that reproduces the
> bug?
>
> > 1. That XPath::executeMore not return a null nodeset() or, at least,
>
> that
>
> > XPathEvaluator::selectNodeList not try to nodeset() on a *XObjectPtr
>
> which
>
> > isn't actually a NodeRefList.
>
> XPath::executeMore() is an internal routine, and you should not attempt to
> call it. If XPathEvaluator::selectNodeList() is using an XObjectPtr
> instance incorrectly, then that's a bug and we will fix it. Just create a
> Jira report, and attach a minimal set of input data, and some
> self-contained code that reproduces the problem.
>
> > 2. To have the XalanTransformer use its parseSource method to parse the
>
> input
>
> > XML once for both the XPath query and then for the transform() method
>
> (rather
>
> > than constructing a separate XalanDocument with the parserLiaison just
>
> for
>
> > the XPath evaluator) and then use the XalanTransformer to parse the
>
> reply XML
>
> > so that the post-transform XPath query can use that without having to
> > construct a new XalanDocument for the output string.
>
> This is trivial. Call XalanTransformer::parseSource(), which create an
> instance of XalanParsedSource for you. Then, you can call
> XalanParsedSource::getDocument() to get the underlying XalanDocument
> instance, which you can pass to any of the XPathEvaluator member
> functions.
>
> Dave
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
