On a related note, I see that a XalanTransformer has a method to parse - but not transform - an XML input into a XalanDocument. If so, and I don't need a mutable DOM, and I already have a XalanTransformer instance, then can't I use the "simpler" XalanTransformer::parseSource method instead of the parserLiaison technique in the SimpleXPathAPI and SerializeNodeSet sample examples?
On Thursday 16 June 2005 08:03 am, Lonnie VanZandt wrote: > I was testing XObjectPtr::get() != NULL but this isn't the same result > as !XObjectPtr::null(). If I use the latter, the test following the > evaluate() call (for !null()) fails (the XObjectPtr _is_ null) and so the > troublesome XObjectPtr->nodeset() call is avoided. > > But, why is evaluate returning a null XObjectPtr which selectNodeList is > failing to check? > > On Thursday 16 June 2005 06:37 am, Lonnie VanZandt wrote: > > Hmm, if I replace the selectNodeList call with a call to evaluate(), the > > evaluate call succeeds without a crash. The XObjectPtr I get back has a > > non-null get() value. However, if I try to convert that XObjectPtr to a > > nodeset via thePtr->nodeset() (just as selectNodeList does) then, > > immediately, the crash occurs. So, clearly, the XObjectPtr isn't pointing > > to a valid NodeRefList nodeset - but, then, what is it pointing to? > > > > On Thursday 16 June 2005 06:12 am, Lonnie VanZandt wrote: > > > Using some code very similar to the samples/SerializeNodeSet example, I > > > currently get a core dump which shows that NodeRefList::operator= tried > > > to dereference a null. (This is Xalan C++ 1.9). > > > > > > The preceding call to selectSingleNode returned a non-null contextNode > > > for a non-null XalanDocument but the selectNodeList call which is given > > > that contextNode and an empty (getLength=0) NodeRefList dumps core. > > > > > > I gather that the internal evaluate call is returning an XObjectPtr > > > whose member pointer is 0. Then when operator= tries to copy > > > theResult->nodeset() into the NodeRefList& which I pass in, the null > > > derefence "fires". > > > > > > Now, it may be that there is a scoping or a memory manager issue which > > > I've overlooked while reading the Xalan C++ API, sample code, and > > > mailing lists. > > > > > > My XPathEvaluator, the NodeRefList, the source XalanDocument, and the > > > context node all have greater, outer scope when selectNodeList gets > > > called. Also, I can dereference the passed in NodeRefList& (via > > > myNodeRefList.getLength()) safely immediately before the selectNodeList > > > call within the same scope. > > > > > > Has this (likely pilot) error been encountered before? > > > > > > Perhaps my XalanDocument, constructed via the parserLiaison > > > parseXMLStream method is somehow malformed? (The original source XML is > > > assuredly well-formed because a peer XalanTransformer has no problems > > > translating it from its original XSLTInputSource...) > > > > > > > > > --------------------------------------------------------------------- > > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
