Yes, you're right: new XPathEvaluator() creates a new Configuration implicitly. There's another constructor that supplies a configuration. You should use that constructor, and supply the Configuration obtained from the transformation context (which is notified to the extension function).

Michael Kay
Saxonica

On 27/12/2011 21:30, Full Midnight wrote:
Thank you again for your help. I went down on the suggested path and below is summarized what happens for each "XML fragment" after being received:

--- XML fragment processing
 // setup
 IndependentContext context = new IndependentContext();
 XPathEvaluator xPathEvaluator = new XPathEvaluator();
 StreamSource source = new StreamSource(new ByteArrayInputStream(xmlFragment.getBytes("UTF-8")));
 Configuration config = xPathEvaluator.getConfiguration(); // the default configuration provided by the XPathEvaluator is used
 NodeInfo inputNode = config.buildDocument(source); // inputNode will be one of the nodes used in the combineNodes() method (from my previous e-mail) and actually returned to the transformation through the int. ext. function.

 // query( xPathQuery )
 xPathEvaluator.setStaticContext(context);
 xPathExpression = xPathEvaluator.createExpression(xPathQuery);
 List<NodeInfo> nodes = xPathExpression.evaluate(node);
 ---

May the above use of the (default XPathEvaluator) configuration cause the exception?
Should I actually use with XPathEvaluator the transformation configuration, which I highly assume is also part of the XPathContext (received as an argument to the ext. function)?

Best regards,
M.

On Mon, Dec 26, 2011 at 1:23 PM, Michael Kay <mike@saxonica.com> wrote:


// Note: for debugging purposes, serializing (using QueryResult.serialize(nodeInfo)) bigNode above does no longer work:
// The exception says: "java.lang.IllegalArgumentException: Unknown name code 1050066"
---

So it looks like the node names get mixed up from some reason, in both cases (i.e. with the context config or with a new one).

Yes, that looks strongly as if a namecode allocated by one Configuration/NamePool is being passed to a different one for resolution. Saxon does try to detect this situation and prevent it, but it probably doesn't catch all cases. Without more info I can't tell exactly what's wrong, but it does look as if there are probably multiple Configuration objects around.

Michael Kay
Saxonica

------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help



------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev


_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
saxon-help@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/saxon-help