Peter Hendry wrote: > To make this a bit more efficient, make read return only the chars up > to the next '>'. that should work. also one can still buffer underlying input in large chunk and then return char-by-char (or smaller chunks as you describe) to xml parser. > More efficient still would be to keep track of the last '<' and > whether it had a '/' after it - then allow returning past '>' if the > last '<' didn't have a '/' (confused? :-) ). not sure if it is going to work with CDATA section (they can contain "unbalanced" XML) > > This working would depend on Xerces not doing read-ahead until it has > reached the end of its previous read. of course but from last time i looked inside X2 it should work ...
best, alek > > Aleksander Slominski wrote: >> Massimo Valla wrote: >> >>> Hi All, >>> I wish to thank all the people for the replies and suggestions about >>> reading multiple XML from a socket (see thread: >>> http://mail-archives.apache.org/mod_mbox/xerces-j-users/200602.mbox/[EMAIL >>> PROTECTED]) >>> >>> Unfortunately no suggestion was useful for our case in which: >>> >>> 1- Server and protocol ***cannot be changed***. Any solution that >>> affects the protocol (markers, parent root tag, etc.) is *not >>> applicable* to our case. >>> >>> 2- XML messages shall be considered finished when the root tag is >>> closed; solutions that wait for the next <?xml to consider the XML >>> message finished are not applicable beacuse the server would send XML >>> messages with some time delay between them >>> >>> The funny thing is that the solution would be exactly the same as in >>> FAQ-11 in Xerces1 >>> (http://xerces.apache.org/xerces-j/faq-write.html#faq-11 ). >>> The fact that a solution to the problem was given as a FAQ means that >>> many people were facing the same problem we have. >>> >>> FAQ-11 was suggesting to solve in 3 steps: >>> STEP-1. Avoid the buffering of the parser by subclassing >>> org.apache.xerces.readers.DefaultReaderFactory >>> STEP-2. Terminate the SAX parse when the root tag is closed by >>> throwing a SAXException >>> STEP-3. Preventing the parser from closing the socket -> subclass >>> BufferedReader to provide an empty close method >>> >>> *FAQ-11 was giving exactly the same solution we are looking for.* >>> *But unfortunately STEP-1 is not applicable to Xerces2, as the >>> internal class org.apache.xerces.readers.DefaultReaderFactory has been >>> moved.* >>> >>> Is there a way to avoid the buffering of the parser in Xerces2 ?? >>> >>> >> hi Massimo, >> >> i think you still can do it without modifying X2 - juts make sure that >> you create a reader class that will returns at most one character in >> read(char[] ...) and its close() method does nothing - i am pretty sure >> this will force X2 to read character by character. it is incredibly >> inefficient - like making car that goes 60mph to go 0.6mph instead but >> should do work (it would be interesting to know ow much slower it is to >> use such reader in X2 ...) >> >> HTH, >> >> alek >> >> > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] For > additional commands, e-mail: [EMAIL PROTECTED] -- The best way to predict the future is to invent it - Alan Kay --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
