Project

Profile

Help

Forums » Help »

net.sf.saxon.tree.linked.DocumentImpl cannot be cast to net.sf.saxon.om.DocumentInfo

Added by Clay Helberg about 8 years ago

Hi--

I'm trying to manage collections in XQuery results, and I am getting this exception:

Caused by: java.lang.ClassCastException: net.sf.saxon.tree.linked.DocumentImpl cannot be cast to net.sf.saxon.om.DocumentInfo at net.sf.saxon.lib.StandardCollectionURIResolver$FileExpander.map(StandardCollectionURIResolver.java:485) at net.sf.saxon.lib.StandardCollectionURIResolver$FileExpander.map(StandardCollectionURIResolver.java:351) at net.sf.saxon.expr.MappingIterator.next(MappingIterator.java:61) at net.sf.saxon.resource.CollectionURIResolverWrapper$1.getResourceURIs(CollectionURIResolverWrapper.java:52) at net.sf.saxon.functions.UriCollection.getUris(UriCollection.java:41) at net.sf.saxon.functions.UriCollection.call(UriCollection.java:97) at gen_ForSequenceMappingAction_line23_1093.map(file:/C:/TerraXML-nodb/Data/fsdb/TerraView/xquery/collections/txml-collections.xq:25) at net.sf.saxon.expr.MappingIterator.next(MappingIterator.java:61) at net.sf.saxon.om.FocusTrackingIterator.next(FocusTrackingIterator.java:61) at net.sf.saxon.expr.ContextMappingIterator.next(ContextMappingIterator.java:59) at net.sf.saxon.om.FocusTrackingIterator.next(FocusTrackingIterator.java:61) at net.sf.saxon.expr.FilterIterator.getNextMatchingItem(FilterIterator.java:77) at net.sf.saxon.expr.FilterIterator.next(FilterIterator.java:64) at net.sf.saxon.expr.sort.DocumentOrderIterator.(DocumentOrderIterator.java:47) at net.sf.saxon.expr.sort.DocumentSorter.iterate(DocumentSorter.java:208) at net.sf.saxon.expr.flwor.ForClausePush.processTuple(ForClausePush.java:34) at EE_main_1115541312501.iterate(file:/C:/TerraXML-nodb/Data/fsdb/TerraView/xquery/pubs/getPublicationConfig.xq:13) at com.saxonica.ee.bytecode.CompiledExpression.iterate(CompiledExpression.java:201) at net.sf.saxon.query.XQueryExpression.iterator(XQueryExpression.java:317) at net.sf.saxon.s9api.XQueryEvaluator.evaluate(XQueryEvaluator.java:433) at com.terraxml.filesysdb.api.FileSysDbApi.getSaxonXqueryResults(FileSysDbApi.java:182)...

Is there something I need to do with my configuration to make this work? I was originally getting a similar error regarding tiny tree document impl, so I switched to the linked tree model, but it didn't help.

Looking at the Javadoc, it looks like net.sf.saxon.tree.linked.DocumentImpl is supposed to implement DocumentInfo, so I'm not sure why the cast is failing. Any insight would be appreciated.

--Clay


Replies (4)

Please register to reply

RE: net.sf.saxon.tree.linked.DocumentImpl cannot be cast to net.sf.saxon.om.DocumentInfo - Added by O'Neil Delpratt about 8 years ago

Hi,

This looks like a bug in our bytecode generation feature. for us to investigate further of what the problem is we would need a repo. Is it possible that you can send us your query either on this post or privately?

If the problem is related to the bytecode generation feature as a workaround you can disable the bytecode feature if running from the API via the Processor class:

processor.setConfigurationProperty("http://saxon.sf.net/feature/generateByteCode", "false");

From the commandline you can do the following:

--generateByteCode:off

RE: net.sf.saxon.tree.linked.DocumentImpl cannot be cast to net.sf.saxon.om.DocumentInfo - Added by Clay Helberg about 8 years ago

Hi O'Neil--

Thanks for your quick response. I tried your suggestion of turning off byte code generation, but there was no change. So I guess it's some other problem.

I will try to work up a minimal test case to demonstrate the problem. Where should I send the files if I don't want to post them publicly?

--Clay

RE: net.sf.saxon.tree.linked.DocumentImpl cannot be cast to net.sf.saxon.om.DocumentInfo - Added by Michael Kay about 8 years ago

I've logged this as a bug here:

https://saxonica.plan.io/issues/2701

Please track it there, rather than here (and in future if you hit a crash like this, feel free to raise it directly on the bug tracker, where we are more careful to ensure that everything eventually reaches closure).

    (1-4/4)

    Please register to reply