I have tested this and do not see the problem
build file:
<project name="x" default="run">
  <target name="run">
    <path id="t.path">
      <path path="build/classes"/>
      <fileset dir="lib" includes="*.jar"/>
    </path>
    <mkdir dir="build/classes"/>
    <mkdir dir="build/test/reports"/>
    <javac srcdir="src" destdir="build/classes"
           target="1.5" source="1.5" debug="yes"
           classpathref="t.path"/>

    <junit fork="true" forkmode="once" showoutput="true">
      <formatter type="brief" usefile="false"/>
      <classpath refid="t.path"/>
      <formatter type="xml"/>
      <batchtest todir="build/test/reports">
        <fileset dir="src" includes="**/*Test.java"/>
      </batchtest>
    </junit>
  </target>
  
  <target name="clean">
    <delete dir="build"/>
  </target>
</project>
and the java files:
peter/T1TEst.java:package peter;

import org.junit.*;

public class T1Test {
    @Test
    public void t1() {
        System.out.println("T1Test::t1");
    }
}
and
package peter;

import org.junit.*;

public class T2Test {
    @Test
    public void t2() {
        System.out.println("T2Test::t2");
    }
}

The xml reports contain the stdout from each test.


I have seen something similar with (shudder) Log4j

At the each of each test, the std output copy is closed
*unless* one uses the follow attribute in the log4j.properties
file.
# attributes for stdout appender
# need to set follow for stdout as it gets moved around in junit tests
log4j.appender.STDOUT.follow=true

Setting to NEEDINFO, it would be nice to have a complete
tar.gz or zip file showing the problem.

Created attachment 26906 [details]
testcase reproducing the problem using java.util.logging

It is easy to reproduce this with JUL (java.util.logging). JUL also caches a reference to System.err.

I just implemented a workaround for this bug in my own codebase by using a formatter created for the task (a la org.apache.tools.ant.taskdefs.optional.junit.TearDownOnVmCrash). My workaround is for users of java.util.logging.

The code for the formatter is available at (I'll add it as an attachment as well):
http://code.google.com/p/plexi/source/browse/test/JUnitLogFixFormatter.java

Use it by adding an additional formatter tag to your build.xml:

<junit...
  ...
  <formatter classname="JUnitLogFixFormatter" usefile="false"/>
  ...
</junit>


At the beginning of each test, the code looks at the root Logger and replaces any ConsoleHandlers it finds with a new ConsoleHandler (and copies over the configuration). ConsoleHandler caches System.err during its constructor, so constructing a new instance is required. After the test completes, the original handlers are replaced back into the root Logger.

For my codebase this seems to work, but YMMV.

Created attachment 27961 [details]
JUnitLogFixFormatter.java

Workaround formatter for java.util.logging users