Celedor
asked on
Parsing XML From a Socket InputStream using Xerces 1.4.4
I'm trying to figure out the problem with using Xerces 1.4.4 to parse XML data that has been passed through a socket... I have no idea whats going wrong. Here's the code used:
InputStream in = socket.getInputStream();
InputStreamReader contentReader = new InputStreamReader(content) ;
InputSource inputsource;
DOMParser domparser = new DOMParser();
domparser.setIncludeIgnora bleWhitesp ace(false) ;
inputsource = new InputSource(contentReader) ;
domparser.parse(inputsourc e);
//Process the DOM Here
The following code works if I manually take the data from the InputStream and turn it to a String, then pass a StringReader over
to the DOMParser.
I also tried using a FileInputStream (to experiment reading from an XML File) instead of using a Socket InputStream by
replacing:
"InputStream in = socket.getInputStream();"
with
"FileInputStream in = new FileInputStream("testXML.x ml");"
and the parser works...
So where could the problem possibly lie?
Thanks in advance!
InputStream in = socket.getInputStream();
InputStreamReader contentReader = new InputStreamReader(content)
InputSource inputsource;
DOMParser domparser = new DOMParser();
domparser.setIncludeIgnora
inputsource = new InputSource(contentReader)
domparser.parse(inputsourc
//Process the DOM Here
The following code works if I manually take the data from the InputStream and turn it to a String, then pass a StringReader over
to the DOMParser.
I also tried using a FileInputStream (to experiment reading from an XML File) instead of using a Socket InputStream by
replacing:
"InputStream in = socket.getInputStream();"
with
"FileInputStream in = new FileInputStream("testXML.x
and the parser works...
So where could the problem possibly lie?
Thanks in advance!
What happens when you try
domparser.parse(new InputSource(new InputStreamReader(socket.g etInputStr eam())));
?
domparser.parse(new InputSource(new InputStreamReader(socket.g
?
Hi,
I think while the data is travelling through sockets, for data integrity purposes, it is converted to bytes, and which has to explicitly casted to string, in case, a user wants to view it.
Regards,
Warturtle
I think while the data is travelling through sockets, for data integrity purposes, it is converted to bytes, and which has to explicitly casted to string, in case, a user wants to view it.
Regards,
Warturtle
ASKER
No exception is being thrown, the parser just hangs (it looks like its waiting for some way to signal the end of the stream, perhaps?).
CEHJ: I'd expect the same thing to happen... But I will give it a try, just to be sure. Thanks!
Reviewing the code I posted up there,
"InputStreamReader contentReader = new InputStreamReader(content) ;"
uses content because its in a different method that accepts an InputStream - but this should be equivalent to:
InputStreamReader contentReader = new InputStreamReader(in);
CEHJ: I'd expect the same thing to happen... But I will give it a try, just to be sure. Thanks!
Reviewing the code I posted up there,
"InputStreamReader contentReader = new InputStreamReader(content)
uses content because its in a different method that accepts an InputStream - but this should be equivalent to:
InputStreamReader contentReader = new InputStreamReader(in);
>>
No exception is being thrown, the parser just hangs (it looks like its waiting for some way to signal the end of the stream, perhaps?).
>>
It's probably either
a. blocking waiting to read bytes that are not yet available on
b. waiting for the sender to close the stream after sending
No exception is being thrown, the parser just hangs (it looks like its waiting for some way to signal the end of the stream, perhaps?).
>>
It's probably either
a. blocking waiting to read bytes that are not yet available on
b. waiting for the sender to close the stream after sending
ASKER
Hmm.. That helps a lot...
That means I can probably test for B by building a lightweight socket sender myself.
How would you test for A?
That means I can probably test for B by building a lightweight socket sender myself.
How would you test for A?
>>How would you test for A?
Just do a test print to System.out. If you're getting any data, it's probably B
Just do a test print to System.out. If you're getting any data, it's probably B
ASKER
Thanks a lot! I will get back to you tomorrow on the results.
ASKER
It seems to be waiting for the entire socket to close, rather than simply the outputstream. Once the socket is closed, the Parser then succesfully parses. But this closes the connection, so no reply can be sent.
I looked at the Java Tutorial client/server implementation, and it seems that the server/client for some sort of "signal" that would signify that the other party has stopped talking, so they could maintain the connection while "conversing".
This being the case, I guess you really have to read it into a String (while having to establish some sort of protocol to signify end of input)? Or is there some other way to fix this?
Thanks again...
I looked at the Java Tutorial client/server implementation, and it seems that the server/client for some sort of "signal" that would signify that the other party has stopped talking, so they could maintain the connection while "conversing".
This being the case, I guess you really have to read it into a String (while having to establish some sort of protocol to signify end of input)? Or is there some other way to fix this?
Thanks again...
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
There's a way to handle this probably - do i take it that you know the incoming message format Celedor?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Right. That about solves the problem.
CEHJ, that's very similar to how I did it. But now, thanks to you, I have a much better understanding of the problem.
orangehead911, that's an interesting pattern which could prove useful to know.
You've both been very very helpful... Thanks a lot! :-)
CEHJ, that's very similar to how I did it. But now, thanks to you, I have a much better understanding of the problem.
orangehead911, that's an interesting pattern which could prove useful to know.
You've both been very very helpful... Thanks a lot! :-)
8-)
My pleasure! :-)
InputStream in = new BufferedInputStream(socket