-
Bug
-
Resolution: Cannot Reproduce
-
P4
-
5.0
-
x86
-
windows_2000
FULL PRODUCT VERSION :
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 Professional
Version 5.0.2195 Service Pack 4 build 2195
EXTRA RELEVANT SYSTEM CONFIGURATION :
1 Gb physical memory
A DESCRIPTION OF THE PROBLEM :
I am parsing a large xml input file (3200 lines) with the XMLStreamReader mechanism (I used the CursorParse example). Within the document element ('settings' in example), the xml file contains about 130 of the same elements ('setting' in example):
<settings>
<setting id="1">
<attr name="a"/>
....
</setting>
<setting id="2">
...
With the getAttributeValue method of my XMLStreamReader, I am getting the value of the 'id' attribute when the XMLStreamReader points to a startElement with the getLocalName is 'setting'.
As a result, I am getting all the id's, except for two. For these incorrect 'ids', I get a part of the xml input file (text including half an element name, a carriage return and again half an element name). The resulting text is in the xml input file (but about 200 lines further then where the XMLStreamReader is pointing to). The result is also not element text or an attribute value, but it is a text snippet from the xml file.
When I removed the 'setting' blocks that went wrong from the xml file, the same error occured again, but now on the next 'setting'.
When I shorted the xml input file the problem disappeared.
As magic, I could 'solve' the problem by exchanging two 'setting' blocks in the xml file.
I am very confident that the problem is not in my parsing code and/or the input xml file. All indications point to the problem being in the parser.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a large xml input file with a large number of 'identical' blocks.
Setup the CursorParse example to walk through the xml file,
while loop to handle each 'identical' block.
Retrieve an attribute from the first element of each 'identical' block, and make it visible (e.g. System.out).
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I expected of course, the correct 'id' values for ALL 'setting' elements that I parsed.
ACTUAL -
Verify if all retrieved attributes have the correct value.
For me, this was not the case. At two places the result was incorrect.
REPRODUCIBILITY :
This bug can be reproduced always.
###@###.### 2005-05-03 05:51:29 GMT
java version "1.4.2_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02)
Java HotSpot(TM) Client VM (build 1.4.2_03-b02, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows 2000 Professional
Version 5.0.2195 Service Pack 4 build 2195
EXTRA RELEVANT SYSTEM CONFIGURATION :
1 Gb physical memory
A DESCRIPTION OF THE PROBLEM :
I am parsing a large xml input file (3200 lines) with the XMLStreamReader mechanism (I used the CursorParse example). Within the document element ('settings' in example), the xml file contains about 130 of the same elements ('setting' in example):
<settings>
<setting id="1">
<attr name="a"/>
....
</setting>
<setting id="2">
...
With the getAttributeValue method of my XMLStreamReader, I am getting the value of the 'id' attribute when the XMLStreamReader points to a startElement with the getLocalName is 'setting'.
As a result, I am getting all the id's, except for two. For these incorrect 'ids', I get a part of the xml input file (text including half an element name, a carriage return and again half an element name). The resulting text is in the xml input file (but about 200 lines further then where the XMLStreamReader is pointing to). The result is also not element text or an attribute value, but it is a text snippet from the xml file.
When I removed the 'setting' blocks that went wrong from the xml file, the same error occured again, but now on the next 'setting'.
When I shorted the xml input file the problem disappeared.
As magic, I could 'solve' the problem by exchanging two 'setting' blocks in the xml file.
I am very confident that the problem is not in my parsing code and/or the input xml file. All indications point to the problem being in the parser.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Create a large xml input file with a large number of 'identical' blocks.
Setup the CursorParse example to walk through the xml file,
while loop to handle each 'identical' block.
Retrieve an attribute from the first element of each 'identical' block, and make it visible (e.g. System.out).
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I expected of course, the correct 'id' values for ALL 'setting' elements that I parsed.
ACTUAL -
Verify if all retrieved attributes have the correct value.
For me, this was not the case. At two places the result was incorrect.
REPRODUCIBILITY :
This bug can be reproduced always.
###@###.### 2005-05-03 05:51:29 GMT