Stopping cargo Tomcat container corrupts output log file

CARGO-607

I'm still seeing this issue re-occur under 1.0 snapshot.

this wasn't a duplicate

this is a simple issue. each maven2 plug-in operation calls createContainer(), which in turn creates a logger with append set to false.

I will change that setting to true. If users want to clean logs, they should use the normal maven clean phase.

same issue affects the ant and samples plug-in

should be ok now

I'm still seeing the output logs get stomped when I if I have a stop execution. This is using the snapshot from 10 march.

I am still seeing this issue when using Cargo 1.0 plugin and FailSafe 2.5

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 {
    // do stuff with container that generates some output
}
finally {
    container.stop(); // clobbers output.log
}

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); // prevent clobbering output
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.

The fact that there is a generated output proves that the output log contains something

The best solution would be the log file to append by default.

Is this issue related to CARGO-648 in any way? It's marked as fixed.

Workaround is to call:

container.setAppend(true);

As of CARGO 1.0.3, the default value for append will be true.

Committed revision 2441.

Fix CARGO-520 (Stopping cargo Tomcat container corrupts output log file) by making the 'append' attribute's default value 'true'

The fix sounds much better than the current situation, but I'm not sure it's the most optimal situation. Wouldn't it be better if the append is always true when calling the container.stop()?

Imagine this situation:

• you set append=false to ensure that Cargo overwrites output.log if it already exists
• you start the container, some logging gets stored in the file
• you stop the container
• stopping the container still clobbers the output.

The problem is the reuse of the code between start() and stop() in AbstractInstalledLocalContainer. The append behaviour needs to be configurable in the start() method, but always true in stop().

I agree.

TODO: revert and do as Matt suggested.

Very good! Thanks Matt!

Fixed rev. 2443.

Thanks guys. Fix looks good to me.