waldenner / robotframework

Automatically exported from code.google.com/p/robotframework
Apache License 2.0
0 stars 0 forks source link

invalid xml generated #512

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
We have a case where robot is generating invalid XML. I've attached the
file. We're getting the following error message:

 [Fatal Error] dummy%20base%20uri:2236:3: The element type "kw" must be
terminated by the matching end-tag "</kw>".
[ ERROR ] Opening XML file
'/home/dball/dev/orbitz-web-wl/orbitz-web-wl-regression/servicetest/report/robot
/output.xml'
failed: SAXParseException: The element type "kw" must be terminated by the
matching end-tag "</kw>".

This is with robot framework 2.1.3

Original issue reported on code.google.com by bryan.oa...@gmail.com on 26 Mar 2010 at 8:25

Attachments:

GoogleCodeExporter commented 9 years ago
It's pretty hard to debug this without more information about the context where 
this
happens. It would be best if you could provide an example test that can be used 
to
reproduce the issue. 

Notice also that OutputFileFixingTool can be used to recover information from 
the file.

Original comment by pekka.klarck on 26 Mar 2010 at 9:34

GoogleCodeExporter commented 9 years ago
Bryan, do you have any more information about this issue?

Original comment by pekka.klarck on 12 Apr 2010 at 8:37

GoogleCodeExporter commented 9 years ago
No, no more information. Unfortunately it's in a large test suite that can't be
refactored down to a smaller test. All I know is that there is a <kw> tag near 
the
end that doesn't have a closing tag. 

Original comment by bryan.oa...@gmail.com on 12 Apr 2010 at 8:51

GoogleCodeExporter commented 9 years ago
Does that happen every time? Does OutputFileFixingTool help? If you are using
timeouts, could you disable them and see does that have any effect? Is this only
Jython or does it happen with Python too?

Original comment by pekka.klarck on 12 Apr 2010 at 9:17

GoogleCodeExporter commented 9 years ago
I don't know the answer to any of those questions and my day is booked solid
tomorrow. I'll try to take a look at it on Wednesday.

Original comment by bryan.oa...@gmail.com on 12 Apr 2010 at 9:27

GoogleCodeExporter commented 9 years ago
OK. No big hurry here, but if we don't get any more information we cannot do 
anything
else than close this issue. If that happens, you can obviously submit a new 
issue
when you have more information.

Original comment by pekka.klarck on 12 Apr 2010 at 9:42

GoogleCodeExporter commented 9 years ago
We cannot do anything to this without more information.

Original comment by pekka.klarck on 28 Apr 2010 at 7:23

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
I saw this error again today, and noticed something that might be a clue to the 
problem. In investigating I discovered that my user had both a test case, test 
file and library keyword all with the same name, and the test case was 
attempting to call the library keyword.

Maybe robot was getting stuck in a recursive loop? We're still investigating 
but my guess is, when the user renames his objects the problem will go away. I 
can't duplicate this with a really simple test case so maybe it's a red herring.

Food for thought.

Original comment by bryan.oa...@gmail.com on 9 Jun 2010 at 8:50

GoogleCodeExporter commented 9 years ago
It's possible to create recursion with user keywords (issue 551) but I don't 
know how that could happen with library keywords unless the recursion is in the 
keyword's code. Anyway, let us know if you find more information about the 
problem.

Original comment by pekka.klarck on 9 Jun 2010 at 9:18

GoogleCodeExporter commented 9 years ago
We discovered we did indeed  have a library keyword written in java that had 
the same name as a test case. When the user renamed the java keyword and 
recompiled, the problem went away. 

That's what's been reported to me; unfortunately I haven't had the time to step 
through robot code as it's running to verify, and I haven't had a chance to try 
and create a small reproducible test case that's not dependent on our whole 
infrastructure. 

It looks like this, issue 551 and issue 512 are all the same. While it may not 
be possible to prevent or even necessarily detect recursion, it would be good 
if the report writer could properly catch such problems and at least leave us 
with a well formatted xml file.

Original comment by bryan.oa...@gmail.com on 9 Jun 2010 at 9:31