Re: Bug: Input Stream not closed in unparsed-text()

You are indeed correct.

Closing a BufferedReader wil close the underlying Reader specified at  
construction.

Given that the reader is a InputStreamReader, the underlying  
InputStream will be closed when the InputStreamReader is closed.

So, IMVHO, in this case "reader.close()" makes more sense than  
"is.close()".

    Pier

On 21 Jun 2005, at 21:57, Michael Kay wrote:

> Thanks, I'll fix this.
>
> (Shouldn't one technically close the Reader rather than the underlying
> InputStream? I don't suppose it makes any difference in practice.)
>
> Michael Kay
> http://www.saxonica.com/
>
>
> > -----Original Message-----
> > From: saxon-help-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> > [mailto:saxon-help-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx] On 
> > Behalf Of
> > Christian Roth
> > Sent: 21 June 2005 21:33
> > To: Saxon-Help Mailing List
> > Subject: [saxon] Bug: Input Stream not closed in unparsed-text()
> >
> > Hello,
> >
> > in net.sf.saxon.functions.UnparsedText, the InputStream for
> > reading from
> > the specified URL is not explicitly closed after retrieving the data.
> >
> > This has the negative side effect that the read-from file can
> > be deleted
> > or modified only after a garbage collector run. I have
> > created some sort
> > of batching capability in Java where Saxon is one task, and
> > the deletion
> > of the source file the immediately following one. On Windows,
> > the delete
> > operation fails with a "file is in use" error.
> >
> > I verified that after having the garbage collector run in
> > some way after
> > Saxon finishes, the lock is relinquished. I modified the source of  
> > the
> > readFile() method to read:
> >
> >
> > ...
> >            while (true) {
> >                 actual = reader.read(buffer, 0, 2048);
> >                 if (actual<0) break;
> >                 sb.append(buffer, 0, actual);
> >             }
> > /* --> */   is.close();                   // <- added [rC]
> >             return sb.condense();
> > ...
> >
> > After that, I could delete the file immediately.
> >
> > Could you please check if this is a reasonable fix and does not pose
> > problems for other sorts of InputStream (e.g. from a http connection
> > instead of the local file system)? If it is ok, please
> > consider adding it
> > in an upcoming release.
> >
> > Kind regards
> > Christian Roth
> >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration  
> > Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> > _______________________________________________
> > saxon-help mailing list
> > saxon-help-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> > https://lists.sourceforge.net/lists/listinfo/saxon-help
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> saxon-help mailing list
> saxon-help-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@xxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/saxon-help

smime.p7s
Description: S/MIME cryptographic signature