Issues with the fromXML method and streams

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Issues with the fromXML method and streams

Erik Wiklund
Hi, I'm using xstream 1.4.3 and since searching both the documentation and bug tracker didn't yield anything useful I'll just leave this here.

I have come across a problem with the fromXML (InputStream) method, when used in conjunction with the ZipInputStream, reading a single compressed file (entry) from an archive causes the entire stream to close. This behaviour is unexpected since it is not documented and also makes processing multiple xml-files from a single zip-archive require extra work. Now, I have already managed by converting each file to a string before calling toXML (String) which will work as expected, however this should probably be considered a bug or at minimum be documented.

Also toXML (Reader) seems to be affected.

Expected behaviour should be that the provided stream is not explicitly closed by fromXML, regardless of end-of-stream state.

Example:
XStream XSTREAM = new XStream(new DomDriver("UTF-16"));
ZipInputStream in = new ZipInputStream(new File("xmlfiles.zip"));
ZipEntry ze = null;
while((ze = in.getNextEntry()) != null)  {
// here each file in the zip-archive is normally processed by reading from "in".
XSTREAM.fromXML(in); // this will cause "in" to be close after processing the first file in the zip-archive.
in.closeEntry(); // will throw an exception since "in" is no longer open.
}
in.close(); // the zip-file is supposed to be closed here, after processing each file inside.

Reply | Threaded
Open this post in threaded view
|

Re: Issues with the fromXML method and streams

Jörg Schaible-3
Hi Erik,

Erik Wiklund wrote:

> Hi, I'm using xstream 1.4.3 and since searching both the documentation and
> bug tracker didn't yield anything useful I'll just leave this here.
>
> I have come across a problem with the fromXML (InputStream) method, when
> used in conjunction with the ZipInputStream, reading a single compressed
> file (entry) from an archive causes the entire stream to close. This
> behaviour is unexpected since it is not documented and also makes
> processing multiple xml-files from a single zip-archive require extra
> work. Now, I have already managed by converting each file to a string
> before calling toXML (String) which will work as expected, however this
> should probably be considered a bug or at minimum be documented.
>
> Also toXML (Reader) seems to be affected.
>
> Expected behaviour should be that the provided stream is not explicitly
> closed by fromXML, regardless of end-of-stream state.
>
> Example:
> XStream XSTREAM = new XStream(new DomDriver("UTF-16"));
> ZipInputStream in = new ZipInputStream(new File("xmlfiles.zip"));
> ZipEntry ze = null;
> while((ze = in.getNextEntry()) != null)  {
> // here each file in the zip-archive is normally processed by reading from
> "in".
> XSTREAM.fromXML(in); // this will cause "in" to be close after
> processing the first file in the zip-archive.
> in.closeEntry(); // will throw an exception since "in" is no longer open.
> }
> in.close(); // the zip-file is supposed to be closed here, after
> processing each file inside.

Well, XStream does *not* close an InputStream.

However, you explicitly have selected a Driver that uses a XML parser that
does *not* support streams on its own. Any DOM parser will have to read the
*complete* input stream before it can create the DOM for the processed XML
and I can imagine that it will also automatically close the stream.

- Jörg





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Issues with the fromXML method and streams

Erik Wiklund
> Hi Erik,
>

>
> Well, XStream does *not* close an InputStream.
>
> However, you explicitly have selected a Driver that uses a XML parser that
> does *not* support streams on its own. Any DOM parser will have to read the
> *complete* input stream before it can create the DOM for the processed XML
> and I can imagine that it will also automatically close the stream.
>
> - Jörg
>

Of course, now I feel stupid. Well, thanks for clarifying. I'll have to look into my XML-driver choice.

Cheers