National Research Council<br />Internet Logic Department
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
National Research Council<br />Internet Logic Department
Clivant Yeo
My Personal Website
National Research Council<br />Internet Logic Department
Clivant's code runs on the server. Both the client and server each have their own sockets, and the sockets are connected to each other over the network. But note that their streams are "crossed": whatever the client writes to its socket's output stream shows up on the server's socket's input stream and vice versa.Originally posted by luc comeau:
doesnt this suggest that the servers input stream is going to be dependant on what the clients inputstream is?
National Research Council<br />Internet Logic Department
National Research Council<br />Internet Logic Department
National Research Council<br />Internet Logic Department
National Research Council<br />Internet Logic Department
National Research Council<br />Internet Logic Department
National Research Council<br />Internet Logic Department
National Research Council<br />Internet Logic Department
I was trying to trick you but you foiled my plan again! Actually, I should point out that I've never used DataInput/OutputStream -- I was just going from the JavaDocs. Ah, I see why it failed. write(int b) treats the int as a byte and just writes the low 8 bits, so when you called readInt() on the other side, it used the 8 bits of the int written plus the first 24 bits of the file. In any case, good catch.Originally posted by luc comeau:
lol, simple but honest mistake.
That would work just fine in your case. You have another option as well which would be required if you needed to have the server send something after the XML file. Since you don't, you should be able to skip reading into the byte[] (and skip sending/reading the length, though it doesn't hurt), and simply hand the InputStream off to the SAXBuilder.I was thinking, and i saw one that takes in a input stream, maybe instead of wrtiing my byte buffer to a file i could just perhaps return the stream and use that streeam to do a build on my documnet?
It's not a problem to use it, obviously, but I don't see why it would be necessary. Just out of curiosity, can you elaborate on the problem you had using File?i had to use RandomAccessFile
Just out of curiosity, can you elaborate on the problem you had using File?
What is the exception you get when deleting the File? Perhaps the SAXBuilder still has the File open for reading, but that's just a total guess.
National Research Council<br />Internet Logic Department
Well as you know i had an array of bytes to use to build a new file from, but if you look at all of the methods for File class there is one to
write (byte[]),
National Research Council<br />Internet Logic Department
LOL, ya I had to read it twice, but I got it.Originally posted by luc comeau:
well this didnt obviosuly make any sense ... its suposed to say "...for the File class there IS NOT one to...."
FileOutputStream is what you wanted.It's just a matter of getting familiar with the various classes in the java.io package. There are quite a few, and they've evolved with each JDK (1.4 introduced an entirely new way of deaiing with I/O called New I/O that uses Buffers and Channels), so it's not an easy task. You might want to go through the Sun tutorial as I believe it covers the differences between streams and readers/writers. It should also cover the buffered versions of each.but if you look at all of the methods for File class there is [not] one to write (byte[])
I forgot that File.delete() returns false when it cannot delete it rather than throwing an IOException telling you why it couldn't be deleted. Since SAX is a callback-oriented API -- it doesn't build an entire Document at once but rather calls your callback methods as pieces are read from the stream -- I figured it may still leave the File and its InputStream open. However, given that build() returns a Document, I'm guessing SAXBuilder uses SAX to read in and build the entire Document. If that's the case, it should close the file before returning.It's not throwing an exception.
Wow, enjoy your vacation (?) and take some pics!going to nova scotia in 3 hours.
National Research Council<br />Internet Logic Department
That which doesn't kill us makes us stronger. I think a piece of pie wouldn't kill me. Tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
|