Hi Jukka, --- Jukka Santala <[EMAIL PROTECTED]> wrote: > Fairly straightforward merge from PocketLinux > version, only problem is > neither version of Kaffe has exact implementation.
could you give pat's serialization patch a try and see how that works in your context? You can find the details at: http://www.kaffe.org/pipermail/kaffe/2002-September/008900.html > With Kaffe.org's > version the problem is actually encountered, though > - using Xerces XML > parser, the HTTP code will eat out the headers using > readLine, but then > Xerces will use something else than DataInputStream > to parse the remaining > data. Because that reader doesn't know to eat the > extra line-feed, it gets > stuck at the beginning of the parse-input, which > then doesn't fullfill the > XML-production condition, and causes all XML > documents read over HTTP to > fail. If anybody can come up with an implementation > that doesn't need > mark()/reset(), I'd be happy. If not, this corrects > few exception issues > and at least works, unlike the old code :) Hm. I'm not convinced. There are two ways to handle the \r vs. \r\n ambiguity while reading lines. When a line reading IO class reads a \r it can not tell if that's the beginning of a \r\n newline sequence or just a plain \r newline sequence. One can: a) read one char ahead and check if it's \n; push it back if it isn't. b) set a flag to ignore the next char if it is \n. I choose the second approach in all IO classes I worked with in order to prevent the classical hung on a socket bug. Imagine a client implementing method a sending a request to a server, that returns a \r terminated reply without closing the socket. The client tries to read ahead and hangs because the server has nothing left to send. Ugly. Check out http://developer.apple.com/technotes/tn/tn1157.html for more information on this bug. I switched DataInputStream to method b recently for that reason. I don't think going back to the previous version is a good idea, as it fixes one bug by introducing another. Instead of using mark and reset one could use a pushback input stream with a single byte buffer, but that's still method a. In any case it would be great if you could come up with a small test for the regression test suite as this bug is not covered by it and we don't have that many networking tests anyway. It may be a bug in our HTTP handling code, for example. A small test could help me come up with a less invasive solution ;) best regards dalibor topic __________________________________________________ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com _______________________________________________ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
