Project

Profile

Help

Bug #2111

closed

setConfigurationProperty prevents propagation of ModuleURIResolver

Added by Michael Kay over 10 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
XQuery Java API
Sprint/Milestone:
Start date:
2014-07-23
Due date:
% Done:

100%

Estimated time:
Legacy ID:
Applies to branch:
9.5, 9.6
Fix Committed on Branch:
9.6
Fixed in Maintenance Release:
Platforms:

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

Related to Saxon - Bug #2392: java.lang.RuntimeException: Cannot instantiate a ConfigurationClosedO'Neil Delpratt2015-06-06

Actions
Actions #1

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.

Actions #2

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.

Actions #3

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.

Actions #4

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

Actions #5

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

Actions #6

Updated by O'Neil Delpratt over 9 years ago

  • Related to Bug #2392: java.lang.RuntimeException: Cannot instantiate a Configuration added
Actions #7

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.

Actions #8

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
Actions #9

Updated by O'Neil Delpratt about 9 years ago

  • Sprint/Milestone set to 9.6.0.6

Please register to edit this issue

Also available in: Atom PDF