Bug #4764: StandardModuleURIResolver can't succeed if its default constructor is used - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #4764

closed

StandardModuleURIResolver can't succeed if its default constructor is used

Added by Norm Tovey-Walsh over 3 years ago. Updated about 3 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Norm Tovey-Walsh

Category:

Configuration

Sprint/Milestone:

Start date:

2020-09-29

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

10, trunk

Fix Committed on Branch:

10, trunk

Fixed in Maintenance Release:

10.5

Platforms:

Description

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

Copy link

Updated by Norm Tovey-Walsh over 3 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

Copy link

Updated by Michael Kay over 3 years 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

Copy link

Updated by Norm Tovey-Walsh over 3 years ago

Status changed from New to In Progress

Actions

Copy link

Updated by Norm Tovey-Walsh over 3 years 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

Copy link