Spurious caractères^G (BELL) dans la construction de journaux JUnit CruiseControl barf

Question

J'ai un serveur de construction CruiseControl exécutant un grand nombre de projets. Sur l'un d'entre eux, j'ai récemment remarqué que seule l'une des deux suites de tests est présente dans le rapport de construction (mais les échecs dans l'autre provoquent toujours l'échec de la construction).

Une enquête plus poussée a montré que le fichier de sortie XML de JUnit généré par le XMLFormatter de fourmi (qui CruiseControl parse pour produire créer des rapports) contient des cas occasionnels du code ASCII 7 caractères (BELL), dans une section CDATA contenant le System- sur un cas de test. Cruiscontrol ne peut apparemment pas faire face à cela et xmllint considère également ces charactes illégales dans une section CDATA.

Malheureusement, je ne trouve rien qui puisse écrire ces caractères; ils apparaissent au début d'une ligne particulière de sortie de journal, mais pas toujours (bien que le code de journalisation imprime toujours la même chaîne littérale).

Et le format XML ne devrait-il pas produire du XML valide, peu importe ce qu'un scénario de test écrit dans sa sortie standard?

Est-ce que quelqu'un a eu des problèmes similaires?

Voici comment les sections pertinentes du fichier journal XML ressemble (anonymisées puisque c'est une application d'entreprise):

<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 

Ce code est la production que la sortie du journal:

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

Answer 1

I ont maintenant découvert que les caractères problématiques font partie du flux stdout des tests et sont produits par la méthode beep() de sun.awt.HeadlessToolkit, soit l'implémentation Toolkit utilisée lorsque, comme c'est le cas sur le serveur de compilation, la propriété système java.awt.headless définie sur true.

Il me semble clair qu'il s'agit avant tout d'un bug dans le format XML de ant pour les journaux JUnit, qui (je dirais) devrait produire une sortie XML valide quel que soit le flux stdout.

Édition J'utilisais une ancienne version de ant; la version actuelle (1.7.1) n'a pas ce problème.