Saxon

Legacy ID: #6522621 Legacy Poster: Michael Kay (mhkay)

It shouldn't be necessary for the XdmDestination to know about the Configuration. I suspect that whatever code called getReceiver() then used the resulting Receiver without first initializing its PipelineConfiguration. Was that your code or mine? I think it would be more robust if the getReceiver() call initialized the PipelineConfiguration rather than relying on the caller to do so - that's what other implementations of getReceiver() appear to do, and is the main justification for supplying the Configuration as a parameter to the method. A cleaner design would probably have been to construct Destination objects using factory methods on the Processor, but that would have made it difficult to introduce user-defined Destination classes. As for writing multiple nodes, I guess there's some logic in that - but you can always use XQueryEvaluator.iterate() to return multiple nodes from a query.

Legacy ID: #6522805 Legacy Poster: Michael Kay (mhkay)

>That is, if I use XQueryEvaluator as an Iterator<> and then append the results into a sequence is causing much more overhead then using XQueryEvaluator.run() (assuming the destination could take a sequence) ? >Or is it equivalent ? Using the iterate/evaluate is more efficient than run() if the query is selecting existing nodes from the input, because it avoids creating a copy. If you are constructing new nodes in the query, then it's equivalent. But run() is more efficient in the case of a query that is constructing a new document and serializing it, because it avoids building the result document as a tree.

Legacy ID: #6523058 Legacy Poster: Michael Kay (mhkay)

Actually the specification of Destination.getReceiver() does currently say: It is the caller's responsibility to initialize this Receiver with a {@link net.sf.saxon.event.PipelineConfiguration} before calling its <code>open()</code> method. If you find a Saxon path that is not doing this, please let me know.

Legacy ID: #6524925 Legacy Poster: David Lee (daldei)

Saxon code, not mine. Here's a call path if I dont set the configuration it causes a null pointer except. ---- call statck --------- TinyTree.addNode(short, int, int, int, int) line: 330 TinyTree.addDocumentNode(TinyDocumentImpl) line: 303 TinyBuilder.startDocument(int) line: 134 NamespaceReducer(ProxyReceiver).startDocument(int) line: 98 TreeReceiver.startDocument(int) line: 105 Processor.writeXdmValue(XdmValue, Destination) line: 216 xpath.run(List<XValue>) line: 177 ---------- My code: processor.writeXdmValue(item, ser ); where item is a XdmValue and ser is new XdmDestination() with no further tricks. Your code: documentNumber = config.getDocumentNumberAllocator().allocateDocumentNumber(); Crash, no config.

Legacy ID: #6525075 Legacy Poster: Michael Kay (mhkay)

OK thanks, I've raised a bug and a patch on this: https://sourceforge.net/tracker2/?func=detail&amp;aid=2636940&amp;group_id=29872&amp;atid=397617

Legacy ID: #6530883 Legacy Poster: David Lee (daldei)

Thanks for the fix ! I havent looked at the source of the patch yet, but could you verify that the XdmDestination.reset() method preserves the configuration (or that none is needed after calling reset()) Thanks ... I mention this because I just ran into the side effect of the current code that calling reset() clears the configuration I previously set.

Legacy ID: #6534321 Legacy Poster: Michael Kay (mhkay)

The patch doesn't cause XdmDestination to know or remember the configuration, instead it causes Processor.writeXdmValue() to set the PipelineConfiguration in the Receiver returned by XdmDestination.getReceiver() (which the documentation says it should do). It's possible that other paths could suffer the same problem, and I'm changing the code in the next release so that getReceiver() itself takes responsibility for ensuring the PipelineConfiguration is already set in the returned Receiver.