general policy is fine. So we know what Saxon is supposed to do!
SafeStreamSource workarround mentioned seems to work with Saxon, but fail with
other JAXP compliant systems
when you are sitting close to Norman Walsh, you might consider the
problem once more in more detail:
concerned about the construction of new Templates Objects by parsing from a
2. Many InputStreams (basic, import, include
and entitites) are opened on the fly in the
3. The Stylesheetprocessor does not close the
4. The calling programm does not even know which streams are opened,
cause it is done by the URIResolver,
depends on the source of the XSLT (could even be data dependend with the
5. It seems to be common to reuse URIResolvers, keeping a list
of opened streams in it for later close wouldn't
6. Closing the Streams on
StreamSource.finalize() is premature, since some XSLT
Implementations (not Saxon though),
get the Stream from the Source and then let it
7. Even if we do not reuse URIResolver in a multithreaded fashion,
i.e. create a new one for every parsing process,
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.
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:
Templates construction closes all it's InputStreams (I currently see no
safe way to close the optained InputStreams
I'm also not sure which app should care for the opened and at least
partially read streams after the Templates-Construction
finished. Of course one could start a reset.). This is the opposite of the Saxon
Templates construction closes all resources obtained from URIResolver.resolve
itself, i.e. all Streams obtained
import, include or entities. I'm not sure if this is a difference to
the first suggestion, but one could differentiate
"very first" Source and the imbedded ones.
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.
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
URIResolvers should not be used in multiply threads, should keep lists of
streams which they close on finalization. This
when (7) above is wrong and this can never be too early.
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
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
we've run in another problem with long running processes here. We
feed XML via
new StreamSource(InputStream) sources into Saxon. When stylesheets
Saxon picks them up without stopping the Server process. On the long
run we end
with many open *.xsl Files stopping our server from working. It seems like
Saxons TransformerFactory.newTemplates() method does not close it's
quick hack workarround, returning these below class
does not help, since the call of the InputStream's close now depends
behaviour of garbage collection: Sometimes the SafeStreamSource is
early and than the Stylesheetprocessor fails to read from the now
This Problem is with Saxon 6.5.3. Anything to recommend about