Spurious ^ G (BELL) characters in JUnit log making CruiseControl barf

I have a CruiseControl build server running a large number of projects. On one, I recently noticed that only one of the two test cases is present in the build report (but failures in the other still cause the build to fail).

Further investigation revealed that the JUnit XML output file generated with ant xmlformatter (which is parsed by CruiseControl to generate generation reports) contains random instances of the ASCII code 7 (BELL) character , inside a CDATA containing the system from the test case. Cruiscontrol doesn't seem to handle this, and xmllint also considers these characters illegal in the CDATA section.

Unfortunately, I cannot find anything that could write these characters; they appear at the beginning of a specific line of log output, but not always (although the logging code always prints the same string literal).

And shouldn't xmlformatter produce valid XML no matter what the test case writes to its standard output?

Has anyone had similar problems?

This is what the relevant sections of the XML log file look like (anonymous as this is an enterprise application):

  <testcase classname="Testclass" name="testMethod" time="0.0020"></testcase>
  <system-out><![CDATA[15.10.09 16:49:41.161 (MainUIClass): Starte UI initialize
...
^G15.10.09 16:49:58.881 (SubUiClass): Starte UI initialize
15.10.09 16:49:58.881 (SubUiClass): UI initialize beendet
^G15.10.09 16:49:59.264 (SubUiClass): Starte UI initialize
15.10.09 16:49:59.264 (SubUiClass): UI initialize beendet

      

This is the code that creates this log output:

SystemProperties.getLogger().logInfo(getClass(), "Starte UI initialize");
...
SystemProperties.getLogger().logInfo(getClass(), "UI initialize beendet");

      

+2


source to share


1 answer


Now I have found that the problematic symbols are part of the stdout stream of the tests and are generated by a method beep()

sun.awt.HeadlessToolkit

, that is, the implementation Toolkit

that is used when, as with the build server, the system property is java.awt.headless

set to true

.

It seems clear to me that this is primarily a bug in ant xmlformatter for JUnit logs, which (I would say) should result in correct XML output no matter what is in the stdout stream.



Edit I used an old version of ant; the current version (1.7.1) does not have this problem.

+1


source







All Articles