Hello,
Silly me. On my Win2000 machine I had the .dtd in two locations so it could be seen
by both the client and server. On my WinNT machine I only had it in one location
so it could not be seen by either. For now I hard-coded the location in the DOCTYPE
statement, so I can get this running in some rudimentary fashion. Thanks for pointing
me in the right direction!
So now the behavior is the same on both machines. The client and server exchange
3 messages, and on parsing the 4th message the parser crashes. I can dummy up
the code to send the same message, so this behavior does not seem to depend
on the message content. The xml messages are relatively small, as below in my
original posting.
Here is the function which is used by both the client and server to parse an xml message.
I've even removed the code which walks the tree to retrieve data from the message.
It always crashes the 4th time the parser is called to parse the message.
Anyone see anything obvious I am doing wrong, or can anyone suggest how
to debug this?
Thanks,
Charles
============================================================================
int parse_xml_msg ( char *xml_msg_p )
{
DOMParser parser;
DOM_Node doc;
const char *memBufId = "Xml_Msg";
int rc;
DOMTreeErrorReporter *errReporter = new DOMTreeErrorReporter();
parser.setErrorHandler(errReporter);
MemBufInputSource* memBufIS = new MemBufInputSource (
(const XMLByte*)xml_msg_p,
strlen(xml_msg_p),
memBufId,
false );
try {
parser.parse(*memBufIS); /* Always crashes here 4th time parse_xml_msg is called */
}
catch ( const XMLException& err ) {
return -1;
}
delete[] memBufIS;
delete[] errReporter;
return rc;
}
============================================================================
David N Bertoni/CAM/Lotus@Lotus
 | 
02/06/2002 05:26 PM |  To: [EMAIL PROTECTED] cc: Subject: Re: WinNT vs Win2000 |
Have you installed an ErrorHandler to see if there are any problems parsing
the file? It seems to me from your message that you're assuming that the
file was successfully parsed on NT, and the bug is in walking the DOM
instance, but that may not be true.
In particular, you should see if there is some problem opening the DTD file
on NT vs. Win2000. If the document input is coming from a
MemBufInputSource instance, then you might want to try setting an
appropriate system ID on that instance, so that the system ID of the
DOCTYPE can be resolved in a consistent manner. The other option is to
create and install a custom EntityResolver that knows how to resolve the
system ID properly. That's probably a better solution for this sort of
use-case.
You might also try removing the DOCTYPE temporarily, to see if that clears
up the inconsistency between the two platforms.
Dave
Charles
Prosser/Watson/I To: [EMAIL PROTECTED]
BM@IBMUS cc:
Subject: Re: WinNT vs Win2000
02/06/2002 01:34
PM
Please respond
to xerces-c-dev
Hello,
I've downloaded xerces-c1_5_1-win32.zip.
I've had some success using the DOM api to parse an xml message
created by a client and sent to a server. The server reads the message
from the socket into a buffer and parses it using the MemBufInputSource.
I've borrowed heavily from DOMPrint.cpp, modifying the ostream operator <<
function to my needs.
Here is a sample xml message which I dumped to a file:
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE api_msg SYSTEM "api_msg.dtd">
<api_msg>
<head type="2" app_id="40803e4" synch="1"/>
<info>
<client services="1" host="0000018c.0" application="init" version="8.0"
directory="c:/rundir"/>
</info>
</api_msg>
On a Win2000 machine my code successfully parses this message. Here is
some sample
debug output:
Parse: entered.
Node: name #document, value , type 9.
Found DOCUMENT_NODE.
Parsing child of document.
Node: name api_msg, value , type 10.
Found DOCUMENT_TYPE_NODE.
Parsing child of document.
Node: name api_msg, value , type 1.
Found ELEMENT_NODE.
Parsing child of element api_msg.
Node: name #text, value
, type 3.
Found TEXT_NODE.
Parsing child of element api_msg.
Node: name head, value , type 1.
Found ELEMENT_NODE.
Parsing child of element api_msg.
Node: name #text, value
, type 3.
Found TEXT_NODE.
Parsing child of element api_msg.
Node: name info, value , type 1.
Found ELEMENT_NODE.
Parsing child of element info.
Node: name #text, value
, type 3.
Found TEXT_NODE.
Parsing child of element info.
Node: name client, value , type 1.
Found ELEMENT_NODE.
Parsing child of element info.
Node: name #text, value
, type 3.
Found TEXT_NODE.
Parsing child of element api_msg.
Node: name #text, value
, type 3.
Found TEXT_NODE.
Clearly the code has parsed the entire message and walked through all
children of
the document node and any children of the element nodes.
When I run the same code on a Windows NT machine I get the following debug
output:
Parse: entered.
Node: name #document, value , type 9.
Found DOCUMENT_NODE.
Parsing child of document.
Node: name spch_msg, value , type 10.
Found DOCUMENT_TYPE_NODE.
It appears that the code cannot walk through all the children of the
document node.
When processing a document node ( as in DOMPrint.cpp ) the code does this:
case DOM_Node::DOCUMENT_NODE :
{
DOM_Node child = toParse.getFirstChild();
while( child != 0) {
my_parse_node ( child );
child = child.getNextSibling();
}
break;
}
The function getFirstChild returns a valid node which is parsed by
my_parse_node,
but getNextSibling does not return a valid node so the code exits the while
loop.
Can anyone give me any suggestions what may be causing this difference in
behavior between Win NT and Win 2000?
Thanks for your help,
Charles Prosser
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
