Kevin Steppe wrote:
> This is trivial with Crimson.  In Crimson the default class for building DOM
> objects is a ContentHandler.  Just throw that in or subclass it and you're
> fine.  I suspect you could just take the
> org.apache.crimson.tree.XmlDocumentBuilder code and put that in as your
> ContentHandler.

But that doesn't address his real problem which is creating a
DOM from a *socket*. There is an item in the FAQ about how to
do it in Xerces 1.x, but it's very ugly. Another way to work
around the problems is by using the code for the socket sample
I wrote awhile back for Xerces2.

Check out the samples/socket/io/*.java classes in the Xerces2
alpha release package (or straight from anonymous CVS on the
"xerces_j_2" branch). This works around the problems with the
parser by wrapping both ends of the socket connection when
writing/reading the XML document. Just building a DOm tree
yourself will not solve the inherent problems of transferring
XML documents on a socket (or any stream for that matter)
which doesn't close.

[Note: While it may be trivial in Crimson, it's not the most
optimal solution due to the extra overhead of all of the
method calls. The most optimal method (always) is to reduce
the codepath by building the DOM directly from the internal
callbacks in the parser -- which is what the DOM parser does.]

-- 
Andy Clark * IBM, TRL - Japan * [EMAIL PROTECTED]

Reply via email to