Bug #2701

ClassCastException in StandardCollectionURIResolver

Added by Michael Kay over 4 years ago. Updated about 3 years ago.

Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
9.7, trunk
Fix Committed on Branch:
9.7, trunk
Fixed in Maintenance Release:


Reported here:

A CCE occurs attempting to cast DocumentImpl to DocumentInfo


#1 Updated by Michael Kay over 4 years ago

  • Status changed from New to In Progress

First a bit of background. In 9.6 and earlier, every implementation of a document node implemented the DocumentInfo interface, which itself extended NodeInfo. This allowed the DocumentInfo interface to provide capability defined for a tree as a whole, for example keys, document URIs, etc. The problem with the design was that in many cases we also want this functionality on trees that are rooted at element nodes. This came to a head with the decision in XSLT 3.0 that accumulators (unlike keys) could apply to non-document trees.

So we made a change: instead of DocumentInfo, we would put the "tree-level" information in a new TreeInfo object, which would be associated with every tree whether rooted at a document node or not. This means that in 9.7 DocumentInfo serves very little purpose, but we retained it to keep some commonly-used interfaces compatible. Most notably, it remains the return type of Configuration.buildDocument(). However, it is no longer true that every document node implements DocumentInfo, and in particular the root nodes of the tiny tree and linked tree do not. This means that the StandardCollectionURIResolver is quite wrong to attempt this cast: the code is clearly wrong.

This then interacts with another change in 9.7, which is a complete redesign of the API in the area of collection support. This was also motivated by specification changes, in particular the fact that collection() can now return any kind of object: for example collection applied to a directory containing JSON files can return a sequence of maps. Accordingly, the CollectionURIResolver interface of 9.6 and earlier releases was replaced by the CollectionFinder of 9.7. But we retained some support for CollectionURIResolver for backwards compatibility reasons. The StandardCollectionURIResolver (despite its name) is no longer used unless the application explicitly registers it, or a class derived from it, using the old interfaces. This explains why the exception wasn't encountered in our testing.

#2 Updated by Michael Kay over 4 years ago

  • Status changed from In Progress to Resolved
  • Applies to branch 9.8 added
  • Fix Committed on Branch 9.7, 9.8 added

Patched on the 9.7 and 9.8 branches. Added unit test CollectionTest/testOldStandardCollectionURIResolver which demonstrates that the problem is now cleared.

#3 Updated by O'Neil Delpratt over 4 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release added

Bug fix applied in the Saxon maintenance release.

#4 Updated by O'Neil Delpratt over 4 years ago

  • Sprint/Milestone set to

#5 Updated by O'Neil Delpratt about 3 years ago

  • Applies to branch trunk added
  • Applies to branch deleted (9.8)

#6 Updated by O'Neil Delpratt about 3 years ago

  • Fix Committed on Branch trunk added
  • Fix Committed on Branch deleted (9.8)

Please register to edit this issue

Also available in: Atom PDF