added a comment - - edited
Sorry, but this issue is not fixed in Cargo 1.0.2. It is easy to reproduce with the Java API:
LocalConfiguration configuration = new Tomcat6xStandaloneLocalConfiguration("target/tomcat6x");
configuration.addDeployable(new WAR("path/to/war"));
InstalledLocalContainer container = new Tomcat6xInstalledLocalContainer(configuration);
container.setHome(tomcatInstallationDirectory);
container.setOutput("target/output.log");
container.start();
try {
}
finally {
container.stop(); }
Workaround
A simple workaround in the Java API is to set the output on the container to 'null' prior to calling container.stop():
container.setOutput(null); container.stop();
Root cause analysis
I'm pretty sure the cause of the clobbering is in AbstractInstalledLocalContainer.stopInternal(), which starts a new Java process to stop the container. The stopInternal() method uses the same logic as startInternal() to create the Java process, which means it opens the output file and starts appending to it while the original JVM is still running and writing to the same file.
If this is actually the cause, one potential solution is to make the output file a parameter to the createJavaTask() method. The startInternal() method will pass the configured output file and the stopInternal() method will pass null. This will mean that the JVM which is used to shut down the container will log to stdout, but I think that's not a big problem. In most cases, the shutdown JVM won't produce any output anyway.
CARGO-607