Details
Bug
Closed
Critical
Description
Deserializing a class from an xml previously generated with xStream StaxDriver() cause that the file remain opened until i close the entire application.
A snippet of code that cause the issue :
File file = new File("C:\settings.xml");
XStream xstream = new XStream(new StaxDriver());
xstream.alias("Settings", Settings.class);
Settings s = (Settings) xstream.fromXML(file);
After calling fromXml() the file settings.xml remain locked(i can't remove the file) until the application ends.
A possible ugly workaround seem calling System.gc() after the fromXML() method ...
See this related question on StackOverflow : http://stackoverflow.com/questions/8173124/java-xstream-closing-connection-to-file
Activity
The problem is not resolved even with 1.4.3 version, the file is kept open by the library.
The only working workaround is calling System.gc(); before call delete on the file...
Alessio Pollero
added a comment - The problem is not resolved even with 1.4.3 version, the file is kept open by the library.
The only working workaround is calling System.gc(); before call delete on the file... You're unfortunately right, but the question is, what XStream can do about. If you provide a file or URL, XStream creates a javax.xml.transform.stream.StreamSource (required to resolve external references) which in turn is used as argument for the XMLInputFactory.createXMLStreamReader() creating the javax.xml.stream.XMLStreamReader. The XMLStreamReader will then open the file or URL on its own. When XStream is finished, it does now call since version 1.4.3 the XMLStreamReader.close() method.
However, to my big surprise, StAX 1.0 specification demands that the implementation does not close the underlaying input source. Unfortunately the XMLStreamReader instance is actually the only object, that knows the file handle/socket/... that has to be closed to release the system resource and it is not possible to access it from outside. :-/
Jörg Schaible
added a comment - You're unfortunately right, but the question is, what XStream can do about. If you provide a file or URL, XStream creates a javax.xml.transform.stream.StreamSource (required to resolve external references) which in turn is used as argument for the XMLInputFactory.createXMLStreamReader() creating the javax.xml.stream.XMLStreamReader. The XMLStreamReader will then open the file or URL on its own. When XStream is finished, it does now call since version 1.4.3 the XMLStreamReader.close() method.
However, to my big surprise, StAX 1.0 specification demands that the implementation does not close the underlaying input source. Unfortunately the XMLStreamReader instance is actually the only object, that knows the file handle/socket/... that has to be closed to release the system resource and it is not possible to access it from outside. :-/ Found a solution in current trunk reading from File or URL.
Jörg Schaible
added a comment - Found a solution in current trunk reading from File or URL. 
Fixed in trunk. For now you may use a workaround by invoking the driver directly: