Hi Pete & Alek,
thanks for the discussion and suggestions.
I think I have enough info to try to implement a custom reader that:
- overrides the close() to avoid the SAX parser close the socket on exception (I still cannot understand why a parser that has received a socket as parapmeter, has the right to close it event if he did not open it... it is really an awful behavior to my understanding)
- adds a doClose() { super.close(); } to acctually allow the client to close the socket
- overrides the read(char[] ...) to return data available on the socket until the next '>' (will try the suggested optimization in a second phase)
I will post my code on this forum to get feedback. Possibly it could become a new FAQ for Xerces2 (similar to FAQ-11 for Xerces1).
For the moment, thanks for your help! Any other suggestion for the reader implementation is more than welcome.
Bye,
Massimo
On 3/6/06, Peter Hendry <[EMAIL PROTECTED]> wrote:
The issue is stopping Xerces from reading ahead in the buffer. If SAX is used then the endElement with depth == 0 won't help if Xerces has already pulled in bytes of the next XML document in the stream. That was the original problem. So using SAX alone is not the solution.
Pete
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
