testcontainers/testcontainers-java · warning
can't be reused because it overrides
Error message
{} can't be reused because it overrides {} What it means
GenericContainer.canBeReused() checks that the container subclass does not override containerIsCreated(String); overriding hooks would not run when reusing an existing container, breaking behavior. If an override is found it logs a warning ('{} can't be reused because it overrides {}') and returns false, so reuse (withReuse(true)) is disabled for that class.
Solutions
- Remove the containerIsCreated override and move setup logic into an earlier lifecycle hook (e.g. configure())
- Accept the warning — reuse is intentionally disabled for this subclass
- Subclass differently: apply custom setup before container creation rather than after
Example fix
// before
@Override
protected void containerIsCreated(String containerId) { setup(); }
// after
@Override
protected void configure() { /* setup expressed as config */ } Defensive patterns
Strategy: validation
Validate before calling
// detect reuse-incompatible subclasses early
for (Class<?> t = custom.getClass(); t != GenericContainer.class; t = t.getSuperclass()) {
try { t.getDeclaredMethod("containerIsCreated", String.class);
throw new IllegalStateException(t + " overrides containerIsCreated; reuse disabled"); }
catch (NoSuchMethodException ignored) {}
} Prevention
- Avoid overriding containerIsCreated in reusable container classes
- Express custom setup via configure() instead of post-creation hooks
- Check logs for the 'can't be reused because it overrides' warning when expecting reuse
When it happens
Trigger: Using .withReuse(true) on a container subclass that overrides containerIsCreated; the container silently falls back to creating a fresh instance per run.
Common situations: Custom container classes overriding containerIsCreated for extra setup; upgrading testcontainers while keeping legacy lifecycle overrides; confusion about why container reuse is not taking effect despite identical hashes.
Understand the failure class
Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.
Related errors
- You should never close the global DockerClient!
- This container does not support reuse
- Setter can only be called before the container is running
- Cannot determine HTTP scheme: environment variables are not…
- Elasticsearch containerId is not available. In managed…
AI-assisted analysis of testcontainers/testcontainers-java@8e549514e3 (2026-09-12).
Data as JSON: /api/errors/dc8eef820d00ea5d.
Report an issue: GitHub.
Appendix: source
Thrown at core/src/main/java/org/testcontainers/containers/GenericContainer.java:357
startupAttempts
);
tryStart();
return true;
}
);
} catch (Exception e) {
throw new ContainerLaunchException("Container startup failed for image " + getDockerImageName(), e);
}
}
@UnstableAPI
@SneakyThrows
protected boolean canBeReused() {
for (Class<?> type = getClass(); type != GenericContainer.class; type = type.getSuperclass()) {
try {
Method method = type.getDeclaredMethod("containerIsCreated", String.class);
if (method.getDeclaringClass() != GenericContainer.class) {
logger().warn("{} can't be reused because it overrides {}", getClass(), method.getName());
return false;
}
} catch (NoSuchMethodException | NoClassDefFoundError e) {
// ignore
}
}
return true;
}
private void tryStart() {
try {
String dockerImageName = getDockerImageName();
logger().debug("Starting container: {}", dockerImageName);
Instant startedAt = Instant.now();
logger().info("Creating container for image: {}", dockerImageName);
CreateContainerCmd createCommand = dockerClient.createContainerCmd(dockerImageName);View on GitHub (pinned to 8e549514e3)