Project

Profile

Help

Bug #3455

closed

Transform with -s:https://.... - fails "AugmentedSource not accepted"

Added by Michael Kay about 7 years ago. Updated about 7 years ago.

Status:
Closed
Priority:
Normal
Category:
Command Line
Sprint/Milestone:
-
Start date:
2017-09-20
Due date:
% Done:

100%

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

Actions #1

Updated by Michael Kay about 7 years ago

Confirmed that this does not affect the Java command line, only the .NET command line.

Actions #2

Updated by Michael Kay about 7 years ago

  • Assignee changed from Michael Kay to O'Neil Delpratt
Actions #3

Updated by Michael Kay about 7 years ago

  • Status changed from New to In Progress

We established that this happens because the default URIResolver on .NET returns an AugmentedSource; the main reason for doing this is to set the flag "pleaseCloseAfterUse" to ensure that the InputStream within the Source object gets closed when it has been read. This breaks the usual convention that it is the responsibility of whoever creates a stream to close it later, but that policy isn't possible here because the JAXP interface doesn't provide for a second call to the URIResolver at this point.

I'd suggest tackling this as follows.

Change the specification of DocumentBuilder.build(Source) so:

  1. It does accept an AugmentedSource

  2. If an AugmentedSource is supplied, any options requested in the AugmentedSource take precedence over options set by setting properties on the DocumentBuilder (which in turn take precedence over properties set at the Configuration level).

I think this will be the effect if we simply remove the test

if (source instanceof AugmentedSource) {

throw new IllegalArgumentException("AugmentedSource not accepted");

}

at DocumentBuilder#327, because Configuration.buildDocumentTree() handles an AugmentedSource in this way.

I think this should have the effect that in buildDocumentTree():

  • The options.merge() call on line 4033 causes options.pleaseClose to be true

  • Line 4037 causes finallyClose to be true

  • After (successful or unsuccessful) tree building, line 4073 calls ParseOptions.close(source) should close the Source.

However, there's a snag here, or a couple of snags.

First, Configuration.buildDocumentTree() passes the AugmentedSource to Sender.send(), which re-processes the options in the AugmentedSource. This is probably harmless.

More seriously, ParseOptions.close() does nothing when the source is an AugmentedSource. It should call AugmentedSource.close().

Actions #4

Updated by Michael Kay about 7 years ago

  • Fix Committed on Branch 9.8 added

Changes now committed, and regression-tested on the Java platform.

Still needs a test on a .NET build to check that the original problem has gone away.

Actions #5

Updated by O'Neil Delpratt about 7 years ago

The fix works on .NET. Bug now resolved.

Actions #6

Updated by O'Neil Delpratt about 7 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100
Actions #7

Updated by O'Neil Delpratt about 7 years ago

  • Status changed from Resolved to Closed
  • Fixed in Maintenance Release 9.8.0.5 added

Bug fix applied in the Saxon 9.8.0.5 maintenance release.

Please register to edit this issue

Also available in: Atom PDF