Bug #4764

StandardModuleURIResolver can't succeed if its default constructor is used

Added by Norm Tovey-Walsh about 1 year ago. Updated 7 months 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).


#1 Updated by Norm Tovey-Walsh about 1 year 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.

#2 Updated by Michael Kay about 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)

#3 Updated by Norm Tovey-Walsh 12 months ago

  • Status changed from New to In Progress

#4 Updated by Norm Tovey-Walsh 11 months 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.

#5 Updated by O'Neil Delpratt 7 months ago

  • Applies to branch 10, trunk added

#6 Updated by O'Neil Delpratt 7 months 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