Failure to deploy (CWWKM2011E, CWWKM2187E) when executing 'run' or 'dev', after server is killed without app starting successfully

[scottkurz]

ENV

liberty-maven-plugin v3.8.2.

NOTE:

This is related to some other open issues, see below.

SCENARIO

Say that I kill the Liberty server and dev mode, before my application completes startup. (Another variant would be there is an application error hanging and/or preventing app startup from completing).

I fix my app, and try again with mvn liberty:run or mvn liberty:dev.

SYMPTOM

The dev/run execution fails to start successfully. I get errors like:

[INFO] CWWKM2011E: Timed out searching for CWWKZ0001I.*my-app in C:\my-app\target\liberty\wlp\usr\servers\default\logs\messages.log.

...

[ERROR] Failed to execute goal io.openliberty.tools:liberty-maven-plugin:3.8.2:dev (default-cli) on project my-app: CWWKM2187E: Failed to deploy the my-app application. The application start message was not found in the log file. -> [Help 1]

ROOT CAUSE

As in #1536, the cause is that in DeployMojoSupport.java we do a check

protected void verifyAppStarted(String appFile) throws MojoExecutionException {
    if (shouldValidateAppStart()) {

and decide that we SHOULD validate, because the server is running. But actually, the server is not running. We think this just because the server was stopped/killed abruptly without cleanup, and so, e.g. the .sRunning file is left hanging around and we think the server is still running. So the app start has not had a chance to occur on the present execution, and we then fail to find a match.

WHY THIS DOESN'T HAPPEN MORE

This would appear to work fine if the app had started successfully before the server had been previous killed. In this case, the 'messages.log' would indeed contain the CWWKZ0001I we're searching for, (even though it's kind of a bad check because it's matching against some previous start).

RELATION TO OTHER ISSUES

The difference btw. this case and #1536 case is that in that case there's no messages.log
because of the issue #1684
of failing to honor non-default outputDirectory when writing logs.

At this point, #1536 could probably be closed and the remaining issues worked separately. The writeup there is probably confusing.

WORKAROUND

Do a clean first.