Hmm, if I move away from the parserLiaison objects for constructing the XalanDocuments of the XML strings, then I need to find an XalanSourceTreeDOMSupport for the XPathEvaluator calls. I have to go review the APIs to see where to borrow/construct one...
On Thursday 16 June 2005 01:09 pm, Lonnie VanZandt wrote: > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
