DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27081>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27081
Too much malformed data is reported
elharo@xxxxxxxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |
------- Additional Comments From elharo@xxxxxxxxxxxxxxx 2004-02-21 01:53
-------
I can reproduce this bug, and a test case will be attached shortly. The test
case requires the use of XOM, but could probably be cut down not to use it. XOM
is only used to read the list of files in the W3C test suite, which this case
expects to find in a directory named xmlconf in the current working directory.
I have established that the bug only appears when you run the test cases in
order. That is, it is not enough to check just 027.xml. You have to check 01.xml
through 026.xml first. That's probably why sax.DocumentTracer did not reproduce
this. Weird. I can't explain it, but this is the behavior I see.
My supposition that this was related to a custom parser configuraiton did not
bear out. When I turned off the custom parser ocnfiguration XOM normally loads,
the bug remained.
|
