Dev container mode issues

[venmanyarun]

Background

Running libertyDevc in a multi-module project — where several submodules each have their own Liberty server configured — exposes three separate defects that together make it impossible to start more than one module in container dev mode on the same machine. They share the same scenario and the same root area in DevUtil.java, so they are tracked together.

Scenario used to reproduce all three
Project myApp has three independently Liberty-configured submodules (A, B, C), each with its own Dockerfile:

myApp/
  A/  build.gradle (or pom.xml)   Dockerfile
  B/  build.gradle (or pom.xml)   Dockerfile
  C/  build.gradle (or pom.xml)   Dockerfile
  settings.gradle (or pom.xml)

Starting each module in a separate terminal:

# Gradle
gradle :A:libertyDevc
gradle :B:libertyDevc
gradle :C:libertyDevc

# Maven
mvn liberty:devc -pl :A -am
mvn liberty:devc -pl :B -am
mvn liberty:devc -pl :C -am

Issue 1 :- Container name collision — all modules default to "liberty-dev"

Affects: Maven + Gradle

Actual behaviour

Starting a second module fails immediately. Both modules attempt to use the same default container name "liberty-dev", causing the container engine to reject the second:

Error: creating container storage: the container
name "liberty-dev" is already in use by
d7b017a907bd...

You have to remove that container to be able
to reuse that name.
Only one Liberty module can run in container dev mode at a time.

Expected behaviour

Each module automatically receives a unique, stable container name that does not conflict with other modules running on the same machine — with no manual configuration required from the user.

Issue 2:- Host port collision when multiple modules start simultaneously

Affects: Maven + Gradle

Actual behaviour

Two or more modules select the same host port for HTTP or HTTPS. The second container to bind the port fails:

A: podman run -p 9081:9080 -p 9444:9443 ...  ✓
B: podman run -p 9080:9080 -p 9443:9443 ...  ✓
C: podman run -p 9080:9080 -p 9443:9443 ...  ✗

Error: cannot bind tcp port :9080:
address already in use

Expected behaviour

Each module is automatically assigned distinct, non-conflicting host ports for HTTP and HTTPS — even when all modules are started at the same time.

Issue 3 :- Default Containerfile/Dockerfile resolved against the root directory instead of the submodule directory

Affects: Gradle only · Maven works correctly

Actual behaviour

• Running gradle :A:libertyDevc without an explicit --containerfile fails even though myApp/A/Dockerfile exists.
• The plugin searches the root project directory instead:
• No Containerfile or Dockerfile was found at /path/to/myApp/Dockerfile.
• Create a Containerfile/Dockerfile at the specified location to use dev mode with container support.

The equivalent Maven command (mvn liberty:devc -pl :A -am) finds A/Dockerfile correctly.

Expected behaviour

When no explicit containerfile is provided, the plugin looks for Containerfile or Dockerfile in the submodule's own directory — consistent with Maven and with how all other per-module configuration is resolved.

[venmanyarun]

Issue 1 Root Cause

Name generation is numeric, module-unaware, and has a race condition

When no --name appears in containerRunOpts, generateNewContainerName() queries all running containers and constructs the next available liberty-dev-N name by finding the highest existing numeric suffix:

// DevUtil.java:1950
private String generateNewContainerName() throws PluginExecutionException {
    String result = execContainerCmdWithPrefix("ps -a --format \"{{.Names}}\"", CONTAINER_TIMEOUT);
    if (result == null) {
        return DEVMODE_CONTAINER_BASE_NAME; // → "liberty-dev" when nothing is running
    }
    // scans for the highest "liberty-dev-N" suffix and increments it
    return DEVMODE_CONTAINER_BASE_NAME + ((highestNum != -1) ? "-" + ++highestNum : "");
}

When two modules start in parallel, both processes execute this query before either container is registered with the engine. Both receive the same list, both compute the same next name, and the second start fails. Even in the sequential case the names (liberty-dev-1, liberty-dev-2) carry no module identity and are fragile across restarts.

The applicationId field (the module/artifact name) is already stored in DevUtil at construction time and is the natural source for a unique, deterministic default name.

[venmanyarun]

Issue 2 Root Cause

HTTP/HTTPS port selection is a TOCTOU probe with no cross-process coordination

getContainerCommand() calls findAvailablePort() independently per module to pick the host-side port mappings for HTTP and HTTPS:

// DevUtil.java:1815
httpPortToUse  = findAvailablePort(LIBERTY_DEFAULT_HTTP_PORT, false);  // tries 9080, 9081…
httpsPortToUse = findAvailablePort(LIBERTY_DEFAULT_HTTPS_PORT, false); // tries 9443, 9444…

findAvailablePort() probes availability by briefly binding a ServerSocket then immediately releasing it before returning the port number.
between the probe close and the container engine actually binding the port, a second concurrently-starting module's probe sees the same port as free and selects it too. The two JVM processes have no shared state to coordinate their selections.

Debug ports already avoid this by using OS-assigned ephemeral sockets (ServerSocket(0)), which guarantees the OS issues a distinct port per call with no inter-process coordination needed. The HTTP/HTTPS selection path does not use this approach.

[venmanyarun]

Issue 3 Root Cause

Gradle passes project.getRootDir() instead of project.getProjectDir() as projectDirectory

The default container file is resolved in the DevUtil constructor against the projectDirectory parameter:

// DevUtil.java:566 — logic is correct; outcome depends entirely on what is passed in
File defaultDockerFile        = new File(projectDirectory, "Dockerfile");
File userDefaultContainerFile = new File(projectDirectory, "Containerfile");
The contract requires projectDirectory to be the individual module's base directory. Maven honours this by passing project.getBasedir(). The Gradle plugin breaks it by passing project.getRootDir(), which always points to the root regardless of which submodule is being started:

// DevTask.groovy:1333 — the source of the bug
this.util = new DevTaskUtil(
    ...,
    project.getRootDir(),  // ← should be project.getProjectDir()
    ...);

The same incorrect base is used in convertParameterToCanonicalFile() (line 261 of DevTask.groovy), meaning explicit relative --containerfile paths also resolve against the root rather than the submodule.