Saxon

Thanks for the further details. I'll investigate when I get access to a Windows machine. The curious thing is not that the common.xsl stream isn't closed the second time, but that it is opened at all: once a stylesheet module has been read, its absolute URI should go in a cache and subsequent includes/imports for the same URI shouldn't get as far as the URIResolver (which is where GetEntity() is called from).

It's also slightly curious that a.xsl is closed twice, though I'm not greatly concerned about that.

Although I don't have a Windows machine with me for hands-on debugging, I've been looking at the source code.

The code in XSLGeneralIncorporate.getIncludedStylesheet() calls DocumentFn.computeDocumentKey() to establish an absolute URI to use for looking up the cache of known stylesheet modules. DocumentFn.computeDocumentKey() has two different paths depending on whether the URIResolver implements the interface RelativeURIResolver. The default URIResolver used on .NET does implement this interface; the one used on Java does not. The key difference is that if the URIResolver is a RelativeURIResolver, then it takes responsibility for resolving a relative URI against an absolute URI, as well as dereferencing the absolute URI to retrieve a resource. This reflects the fact that the Microsoft XmlResolver interface has two methods for these two operations (ResolveURI and GetEntity), while the Java URIResolver interface fails to make this distinction.

The fact that GetEntity is called twice for the common.xsl module suggests that for some reason the document keys computed for the two instances do not compare equal. I can't immediately see why this should be: I'll need to step into it with the Visual Studio debugger (I'm going to have to relearn how to do this - O'Neil is the expert on this and he's on holiday).

The other thing I notice is that the DotNetURIResolver calls the GetEntity method of the underlying XmlResolver on two distinct paths. This reflects the fact that the DotNetURIResolver is used both as a URIResolver (used by the XSLT engine to deference URIs) and as an EntityResolver (used by the XML parser to dereference URIs). The "dereference" method is called when the object is used as a URIResolver, and takes care to call AugmentedSource.setPleaseCloseAfterUse(true). By contrast, the resolveEntity() method, used when the object acts as an EntityResolver, doesn't do anything like this. When Saxon invokes an XML parser, supplying an EntityResolver, it has no control over whether the XML parser closes input files or not.

We attempt to resolve xsl:include references during the "use-when" preprocessing pass over the stylesheet. This code loads a module using StylesheetModule.loadStylesheetModule(). This code calls URIResolver.resolve() and checks whether the returned Source is an AugmentedSource with the property pleaseCloseAfterUse set (which, in the .NET case, it is), and on completion if this property is set, it closes the stream. On this path we pass a Stream to the XML parser (not a URI) so the EntityResolver path shouldn't be invoked. But the fact that a stream is being opened and not subsequently closed does appear to suggest that it was on the EntityResolver path that this happened.

Since you have this running and I don't (yet), it might be revealing to take a stack trace at each call of GetEntity to see where it is called from.

Many thanks. Any idea why there is no stack trace for the final call where a stream for common.xsl is created? Because that's the most interesting one...

Thanks. The second trace makes it clear what's going on.

The UseWhenFilter, when it encounters an xsl:include or xsl:import, does the following

1. Compute a document key (essentially an absolute URI, with some normalization) from the relative URI and base URI.

2. Call the resolve() method of the URIResolver to get a Source

3. if the document key computed at (1) is not in the known set of stylesheet modules, load the stylesheet module from the source computed in (2)

On the java side, by default the URIResolver.resolve() method merely wraps the absolute URI in a SAXSource object and returns. But on .NET, the default URIResolver actually deferences the URI, calling the underlying GetEntity method of the XmlResolver. So we are opening a stream to this resource in step (2); and step (3) then causes this stream to be ignored (not read, and not closed) if the module is already known.

The obvious fix is to skip step 2 if the document key is known, since the Source object obtained is never used.