Bug #2111
closedsetConfigurationProperty prevents propagation of ModuleURIResolver
100%
Description
Reported by Gunther Rademacher on saxon-help list.
When the XQUERY_VERSION configuration property is set before installing a
module URI resolver in the configuration, that URI resolver is not propagated
to XQueryCompiler instances based on that configuration.
This may not be the intended behaviour. Or is it?
Some sample code is shown below. It will complain about the module missing,
but can be fixed by omitting setConfigurationProperty, or by explicitly setting
the module URI resolver in the XQueryCompiler (e.g. by getting from the
configuration).
Best regards,
Gunther
public class ImportModule {
public static void main(String[] args) throws Exception {
final Configuration configuration = new Configuration();
configuration.setConfigurationProperty(FeatureKeys.XQUERY_VERSION, "1.0");
configuration.setModuleURIResolver(new ModuleURIResolver() {
@Override
public StreamSource[] resolve(String moduleURI, String baseURI, String[] locations) throws XPathException {
StringReader reader = new StringReader("module namespace x='x'; declare variable $x:x := 'x';");
StreamSource module = new StreamSource(reader);
module.setSystemId(moduleURI);
return new StreamSource[] {module};
}
});
Processor processor = new Processor(configuration);
XQueryCompiler xqueryCompiler = processor.newXQueryCompiler();
xqueryCompiler.setBaseURI(new File(".").toURI());
XQueryExecutable executable = xqueryCompiler.compile("import module namespace x='x'; $x:x\n");
executable.load().run(new Serializer(System.out));
}
}
Related issues
Updated by Michael Kay over 9 years ago
- Status changed from New to In Progress
What is happening here is that the call to set XQUERY_VERSION causes a defaultStaticQueryContext to be created. The call on setModuleURIResolver() doesn't cause the defaultStaticQueryContext to be updated, but the call on newXQueryCompiler() picks up stuff in the defaultStaticQueryContext. The problem appears to be essentially that the Configuration and the defaultStaticQueryContext each have a link to a ModuleURIResolver, and they can get out of sync.
Updated by Michael Kay over 9 years ago
The right answer seems to be that the configuration should not hold a ModuleURIResolver, but should set it / get it in the default StaticQueryContext; to prevent looping this means that the StaticQueryContext needs to be careful trying to get the ModuleURIResolver from the Configuration.
Updated by Michael Kay over 9 years ago
- Status changed from In Progress to Resolved
Patch committed on the 9.6 and 9.7 branches.
Updated by O'Neil Delpratt over 9 years ago
- % Done changed from 0 to 100
- Fixed in version set to 9.6.0.6
Bug fix applied in the Saxon 9.6.0.6 maintenance release
Updated by O'Neil Delpratt over 9 years ago
- Status changed from Resolved to In Progress
The fix here seems to be causing a regression in .NET. See: https://saxonica.plan.io/issues/2392
Updated by O'Neil Delpratt over 9 years ago
- Related to Bug #2392: java.lang.RuntimeException: Cannot instantiate a Configuration added
Updated by Michael Kay about 9 years ago
- Status changed from In Progress to Resolved
This issue was reopened because the fix caused a regression on .NET. That regression was fixed under bug #2392. It appears therefore that the problem is resolved so I am closing this bug.
Updated by O'Neil Delpratt about 9 years ago
- Status changed from Resolved to Closed
- Applies to branch 9.5, 9.6 added
- Fix Committed on Branch 9.6 added
- Fixed in Maintenance Release 9.6.0.6 added
Please register to edit this issue