Bug #3455
closedTransform with -s:https://.... - fails "AugmentedSource not accepted"
100%
Updated by Michael Kay about 7 years ago
Confirmed that this does not affect the Java command line, only the .NET command line.
Updated by Michael Kay about 7 years ago
- Assignee changed from Michael Kay to O'Neil Delpratt
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:
-
It does accept an AugmentedSource
-
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().
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.
Updated by O'Neil Delpratt about 7 years ago
The fix works on .NET. Bug now resolved.
Updated by O'Neil Delpratt about 7 years ago
- Status changed from In Progress to Resolved
- % Done changed from 0 to 100
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