[XSTR-441] xstream over http

Details

Type: Bug
Status: Closed
Priority: Major
Resolution: Won't Fix
Affects Version/s: 1.2.2
Fix Version/s: None
Component/s: IO
Labels:
None

JDK version and platform:
1.6 for windows

Description

I'm trying to do some basic xstream over http and everything I try results in the following error when parsing via xstream.fromXML(inputStream)

Caused by: org.xml.sax.SAXParseException: Premature end of file.
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source)

code:

HttpURLConnection conn = (HttpURLConnection) new URL(url).openConnection();
conn.setDoInput(true); // allow input stream
conn.setDoOutput(true); // allow output stream
conn.setUseCaches(false); // don't allow caching
conn.setRequestProperty("Content-Type", CONTENT_TYPE_XML_UTF8);
conn.setRequestMethod("POST");
OutputStream out = conn.getOutputStream();
xmlSerializer.toXML(o, out);
out.flush();
InputStream is = conn.getInputStream();
Object ret = xmlSerializer.fromXML(is);
out.close();
is.close();

if I run a sample client against the exact same code but use Strings and a reader it works fine so this would seem to be my problem (likely) or an xstream problem.

(this works)

Reader reader = new InputStreamReader(conn.getInputStream(), "UTF-8");
while ((line=reader.readLine()) != null) {
sb.append(line);
if (reader.ready())

{ sb.append(LINE_SEP); }

}
Object obj = xstream.fromXML(sb.toString());

I tried the same style of approach using commons.httpclient and had the same result.

XStream is configured via:

xstream = new XStream(new DomDriver("UTF-8")); xstream.setMode(XStream.NO_REFERENCES);
addAliases(); // adds a bunch of class name aliases xstream.registerConverter(new NonCachingStringConverter()); // pretty self explanatory

and the full stack trace is as follows....

com.thoughtworks.xstream.io.StreamException: : Premature end of file.
at com.thoughtworks.xstream.io.xml.DomDriver.createReader(DomDriver.java:65)
at com.thoughtworks.xstream.io.xml.DomDriver.createReader(DomDriver.java:51)
at com.thoughtworks.xstream.XStream.fromXML(XStream.java:789)
at (my company's code)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74)
at org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33)
at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75)
at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45)
at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:71)
at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35)
at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42)
at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34)
at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:38)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: org.xml.sax.SAXParseException: Premature end of file.
at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown Source)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown Source)
at com.thoughtworks.xstream.io.xml.DomDriver.createReader(DomDriver.java:58)

one interesting note is that running without the DOM Driver produces a different error

Caused by: java.io.EOFException: input contained no data
at org.xmlpull.mxp1.MXParser.fillBuf(MXParser.java:2983)
at org.xmlpull.mxp1.MXParser.more(MXParser.java:3026)
at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1410)
at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1395)
at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093)
at com.thoughtworks.xstream.io.xml.XppReader.pullNextEvent(XppReader.java:52)
... 33 more

Activity

Hide

Permalink

Jörg Schaible added a comment - 23/Jan/08 7:15 PM

Hi Will,

after rereading your issue and think about it, I am no longer sure, that this is really a problem of XStream in general. The main difference between the StringBuffer based version and the variant that reads directly is the proper character set. See, when you provide XStream an InputStream it has to create a Reader on its own. Unfortunately for the InputStreamReader you have to set the encoding at creation time, but XStream has no clue about the encoding of the incoming data. Note, that the InputStream does not know about an encoding anyway and - since the encoding cannot be changed after creating the reader - any kind of XML header is normally simply ignored. Therefore I assume that your problem arises, because the XML is parsed with the current encoding of the application and not with UFT-8 as you do with the StringBuffer variant. The different exceptions are caused by the different underlaying drivers. A DOM-based driver will first consume the complete XML and build a DOM in the memory before any deserialization can happen, while the default Xpp3 driver is stream-based and it deserializes the objects while the XML is processed. However, in both cases the XML parser itself chokes about invalid XML ... that I assume is caused by the encoding mismatch.

You can reopen this issue if I am wrong and you can convince me about a different problem, but I am quite sure now ...

Show

Jörg Schaible added a comment - 23/Jan/08 7:15 PM Hi Will, after rereading your issue and think about it, I am no longer sure, that this is really a problem of XStream in general. The main difference between the StringBuffer based version and the variant that reads directly is the proper character set. See, when you provide XStream an InputStream it has to create a Reader on its own. Unfortunately for the InputStreamReader you have to set the encoding at creation time, but XStream has no clue about the encoding of the incoming data. Note, that the InputStream does not know about an encoding anyway and - since the encoding cannot be changed after creating the reader - any kind of XML header is normally simply ignored. Therefore I assume that your problem arises, because the XML is parsed with the current encoding of the application and not with UFT-8 as you do with the StringBuffer variant. The different exceptions are caused by the different underlaying drivers. A DOM-based driver will first consume the complete XML and build a DOM in the memory before any deserialization can happen, while the default Xpp3 driver is stream-based and it deserializes the objects while the XML is processed. However, in both cases the XML parser itself chokes about invalid XML ... that I assume is caused by the encoding mismatch. You can reopen this issue if I am wrong and you can convince me about a different problem, but I am quite sure now ...

Hide

Permalink

Jörg Schaible added a comment - 25/Feb/08 4:53 PM

Closed after no further comment has been given.

Show

Jörg Schaible added a comment - 25/Feb/08 4:53 PM Closed after no further comment has been given.

Hide

Permalink

conphident4 added a comment - 25/Jun/12 12:50 PM

Hello,
I am facing the same issue too. Was wondering what is the workaround in this case?

Show

conphident4 added a comment - 25/Jun/12 12:50 PM Hello, I am facing the same issue too. Was wondering what is the workaround in this case?

xstream over http

Details

Description

Activity

People

Dates