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

Question

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

Further investigation showed that the XML output file of JUnit generated by ant's xmlformatter (which CruiseControl parses to produce build reports) contains occasional instances of the ASCII code 7 (BELL) character, inside a CDATA section containing the system-out of a test case. Cruiscontrol apparently cannot deal with this and xmllint also considers these characts illegal within a CDATA section.

Unfortunately, I can't find anything that would write these characters; they appear at the beginning of a particular line of log output, but not always (though the logging code always prints the same string literal).

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

Has anyone had similar problems?

This is how the relevant sections of the XML logfile looks like (anonymized since this is a corporate app):

  <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 producing that log output:

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

Answer 1

I have now found out that the problematic characters are part of the tests's stdout stream and are produced by the beep() method of sun.awt.HeadlessToolkit, i.e. the Toolkit implementation that is used when, as is the case on the build server, the java.awt.headless system property set to true.

It seems clear to me that this is first and foremost a bug in ant's xmlformatter for JUnit logs, which (I'd say) should produce valid XML output no matter what is in the stdout stream.

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