Bug #4764
closed
StandardModuleURIResolver can't succeed if its default constructor is used
Applies to branch:
10, trunk
Fix Committed on Branch:
10, trunk
Fixed in Maintenance Release:
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).
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.
- 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)
- Status changed from New to In Progress
- 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.
- Applies to branch 10, trunk added
- 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
.