Hi Jesse, I tried the sample program StdInParse shipped with Xerces, it runs on my xml file. I tried it out on both Windows, and Linux machines.
The difference between my test program and StdInParse is that my program makes use of XercesDomParser, and StdInParse makes use of SAXParser. I have used the same sort of schema checking and validation flags as used in StdInParse example. Could this be a possible cause? Thanks, Aditya Kulkarni -----Original Message----- From: Jesse Pelton (JIRA) [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 03, 2004 6:45 PM To: Aditya Kulkarni Subject: [jira] Commented: (XERCESC-1297) XercesDomParser::parse() fails with StdInInputSource [ http://nagoya.apache.org/jira/browse/XERCESC-1297?page=comments#action_54972 ] Jesse Pelton commented on XERCESC-1297: --------------------------------------- I'll reiterate what I said on the mailing list yesterday. That's really the correct place to discuss this, since the problem may not be in Xerces. I suspect that the problem is that the document content is altered somehow before your program sees it. I'd run a few command-line tests to see whether this is the case. First, compare the results of "cat sim.xml | hexdump" and "hexdump sim.xml". (I'm assuming your Linux box has hexdump.) It seems likely to me that they will differ, in which case either cat or the pipe has altered the stream. Smart money would be on cat being the culprit, though I don't know why it would change the stream. I'd then try "hexdump < sim.xml". If this gives different results from "hexdump sim.xml", this would indicate that it's the shell, not cat, that's altering the document. That would be even stranger. If all three methods give the same result, then there is indeed something odd going on with Xerces. I'd alter your test program to do a hex dump of the entire stream it's reading, regardless of its source. Don't use printf() to dump the buffer, because it may further alter the data. Any differences in the output between data read from stdin and data read directly from the file will be clues as to what's going on. > XercesDomParser::parse() fails with StdInInputSource > ---------------------------------------------------- > > Key: XERCESC-1297 > URL: http://nagoya.apache.org/jira/browse/XERCESC-1297 > Project: Xerces-C++ > Type: Bug > Components: DOM > Versions: 2.6.0 > Environment: RHAS 3.0, with gcc 3.2.3. Windows 2000, 32-bit, with MSVC7.1 > Reporter: Aditya Kulkarni > > I am passing an instance of StdInInputSource to XercesDomParser::parse() method. An xml file (say a.xml), is piped as input to my test program (say test). The parse method does not throw any exception, but when I find the error count using getErrorCount() method, I get lots of error counts, which indicates parse failure. I am catching all exceptions which the parse method throws. > There are two cases that I would like to discuss. > [1] contents of xml file are piped in: > program invocation on RHAS 3.0: cat a.xml | ./test > In this case, an instance of StdInInputSource is created, and is passed to the XercesDomParser::parse() method. > Result: parse failure, as indicated by error counts > [2] name of xml file is given on command line: > program invocation on RHAS 3.0: ./test a.xml > In this case, an instance of LocalFileInputSource is created and passed to the XercesDomParser::parse() method. > Result: parse success. > Note: > [1] I have not set any encoding for StdInInputSource object. > [2] The default locale on the RHAS 3.0 machine is en.US.utf-8 > [3] The xml file specifies and encoding of UTF-8 on the first line. > What could be the problem? Your response, and help would be greatly appreciated. > Thanks, > Aditya Kulkarni -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
