Thank you again for your help, it really helped me better understand what I was doing wrong.

I have just a few more question regarding the Configuration. I heard that using one Transformer instance for running several transformations in parallel is not recommended.
But in my case I am using one Transformer instance for running one transformation which can receive NodeInfos through the extension function. These NodeInfos are build in other threads in a fashion described in "XML fragment processing" from my previous e-mail.
Can one safely use the transformation Configuration (see config variable below) in other threads for performing serial and/or parallel "XML fragment processing" tasks (as described in my previous e-mail)?
If yes, at which point may "XML fragment processing" start to use the transformation Configuration (before / after XSL processing or..  after XSL and input XML processing)?

--- Transformation Configuration
transformerFactory = new TransformerFactoryImpl();
StreamSource source = new StreamSource(new ByteArrayInputStream(xslDoc.getBytes("UTF-8")));
Configuration config = transformerFactory.getConfiguration();
---

Best Regards,
M.

On Tue, Dec 27, 2011 at 11:10 PM, Michael Kay <mike@saxonica.com> wrote:
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 


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