A general policy is fine. So we know what Saxon is supposed to do!
 
The SafeStreamSource workarround mentioned seems to work with Saxon, but fail with other JAXP compliant systems
(i.e. jdxslt).
 
But when you are sitting close to Norman Walsh, you might consider the problem once more in more detail:
 
1. I'm concerned about the construction of new Templates Objects by parsing from a StreamSource.
2. Many InputStreams (basic, import, include and entitites) are opened on the fly in the URIResolver.resolve()
3. The Stylesheetprocessor does not close the streams.
4. The calling programm does not even know which streams are opened, cause it is done by the URIResolver,
and depends on the source of the XSLT (could even be data dependend with the document() function).
5. It seems to be common to reuse URIResolvers, keeping a list of opened streams in it for later close wouldn't help.
6. Closing the Streams on StreamSource.finalize() is premature, since some XSLT Implementations (not Saxon though),
just get the Stream from the Source and then let it go.
7. Even if we do not reuse URIResolver in a multithreaded fashion, i.e. create a new one for every parsing process,
a list of openend streams would not help, since closing the streams on URIResolver.finalize() could again be premature:
A XSLT processor could release the URIResolver early, still reading from some streams.
 
I'm not entirely sure about the last point, since there could be "late" entitites in Input XSLT, and therefore the
XSLTProcessor might need to keep the URIResolver till the very end of reading it's input?!
 
General solutions I could figure:
 
* The Templates construction closes all it's InputStreams (I currently see no safe way to close the optained InputStreams
and I'm also not sure which app should care for the opened and at least partially read streams after the Templates-Construction
is finished. Of course one could start a reset.). This is the opposite of the Saxon policy :-(
 
* The Templates construction closes all resources obtained from URIResolver.resolve itself, i.e. all Streams obtained
from import, include or entities. I'm not sure if this is a difference to the first suggestion, but one could differentiate between
the "very first" Source and the imbedded ones.
 
* The StreamSource gets an API to notify it can close Streams. Appropriate subclasses can then solve our problem.
 This wouldn't solve our current problem, but the would "fix" it with a new API.
 
* The URIResolver gets an API to notify possible InputStream closes (and becomes then not threadsafe even in the
simplest cases). Which would again not solve our today problem.
 
* The URIResolvers should not be used in multiply threads, should keep lists of streams which they close on finalization. This
works when (7) above is wrong and this can never be too early.
 
Sorry for being fairly long, but it looks like a problem to me. I'd be happy if I'm overlooking a simple solution within the
JAXP framework.
 
Regards,
Frank Nestel
-----Original Message-----
From: Michael Kay [mailto:mhk@mhk.me.uk]
Sent: Tuesday, June 22, 2004 3:06 PM
To: saxon-help@lists.sourceforge.net
Cc: 'Gast, Thorsten IZ/HZA-IOL'
Subject: RE: [saxon] Who is closing the InputStream

My general policy on this (it may not always be correctly implemented) is: he who creates the inputStream is responsible for closing it. So if you create an InputStream and pass it as a Source to Saxon, you should close it on completion. But if you provide a file and Saxon opens the InputStream, Saxon should close it. (I've just checked with Norm Walsh, the spec lead on JAXP 1.3, who happens to be sitting opposite me this morning, and he agrees).
 
Michael Kay


From: saxon-help-admin@lists.sourceforge.net [mailto:saxon-help-admin@lists.sourceforge.net] On Behalf Of Nestel, Frank IZ/HZA-IOL
Sent: 22 June 2004 09:07
To: 'saxon-help@lists.sourceforge.net'
Cc: Gast, Thorsten IZ/HZA-IOL
Subject: [saxon] Who is closing the InputStream

Hello,
 
we've run in another problem with long running processes here. We feed XML via
new StreamSource(InputStream) sources into Saxon. When stylesheets change,
Saxon picks them up without stopping the Server process. On the long run we end
up with many open *.xsl Files stopping our server from working. It seems like
Saxons TransformerFactory.newTemplates() method does not close it's InputStreams.
 
A quick hack workarround, returning these below class from our
handcrafted resolve()
 
public class SafeStreamSource
        extends StreamSource
{
    public SafeStreamSource(InputStream is)
    {
        super(is);
    }
 
    protected void finalize()
        throws Throwable
    {
        super.finalize();
        getInputStream().close();
    }
}
 
does not help, since the call of the InputStream's close now depends on the
behaviour of garbage collection: Sometimes the SafeStreamSource is cleared
early and than the Stylesheetprocessor fails to read from the now closed
InputStream.
 
This Problem is with Saxon 6.5.3. Anything to recommend about this?
 
Thank you,
Frank Nestel