> 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]
