Thanks Jesse for the quick reply. I tried hexdum-ing as you had suggested.
This is what I did.

hexdump sim.xml > out1
cat sim.xml | hexdump > out2
diff out1 out2

hexdump sim.xml > out1
hexdump < sim.xml > out2
diff out1 out2

There was no difference between out1 and out2 in both cases. So, I suspect
there is something wrong in Xerces.

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]

Reply via email to