Bug #4764


StandardModuleURIResolver can't succeed if its default constructor is used

Added by Norm Tovey-Walsh almost 2 years ago. Updated about 1 year ago.

Start date:
Due date:
% Done:


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


At the top of StandardModuleURIResolver, we find:

     * Create a StandardModuleURIResolver. Although the class is generally used as a singleton,
     * a public constructor is provided so that the class can be named in configuration files and
     * instantiated in the same way as user-written module URI resolvers.

    public StandardModuleURIResolver() {


But that constructor leaves config uninitialized. AFAICT, there's no useful code path through the resolver that doesn't attempt to call a method on config (raising an NPE).

Actions #1

Updated by Norm Tovey-Walsh almost 2 years ago

The problem stems from the addition of this test to resolve():

               if (!config.getAllowedUriTest().test(absoluteURI)) {
                    throw new XPathException("URI scheme '" + absoluteURI.getScheme() + "' has been disallowed");

I don't know if it's sufficient to put a guard around that test (if (config != null) ...) or if that test always needs to work in which case, well, I'm not sure what really.

Actions #2

Updated by Michael Kay over 1 year ago

  • Project changed from 4 to Saxon
  • Category set to Configuration
  • Assignee set to Norm Tovey-Walsh
  • Priority changed from Low to Normal

I would suggest

(a) don't do the test if there is no known Configuration (fix needed for 10.x)

(b) after instantiating a ModuleUriResolver, if it extends StandardModuleUriResolver (or conforms to some new to-be-defined interface) then call its setConfiguration() method so it knows the configuration. (this feels more like 11.x)

Actions #3

Updated by Norm Tovey-Walsh over 1 year ago

  • Status changed from New to In Progress
Actions #4

Updated by Norm Tovey-Walsh over 1 year ago

  • Status changed from In Progress to Resolved
  • Fix Committed on Branch 10, trunk added

Per Michael's suggestions:

I've updated the 10.x and trunk so that a missing config doesn't raise an NPE.

In trunk, I've added tests where a ModuleURIResolver is instantiated without a config to provide the config if the instantiated resolver is a StandardModuleURIResolver. This only applies where the resolver is instantiated; it doesn't apply when an already instantiated resolver is passed in from the outside.

Actions #5

Updated by O'Neil Delpratt about 1 year ago

  • Applies to branch 10, trunk added
Actions #6

Updated by O'Neil Delpratt about 1 year ago

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

Bug fix applied to Saxon 10.5 maintenance release.

Please register to edit this issue

Also available in: Atom PDF