testcontainers/testcontainers-java · warning

Multiple versions of Selenium API found on classpath - will…

Error message

Multiple versions of Selenium API found on classpath - will select {}, but this may not be reliable

What it means

SeleniumUtils.determineClasspathSeleniumVersion logs this warning when more than one Selenium API version is detected on the classpath. It picks an arbitrary version (iterator().next()) to select the Docker image, which may not match the Selenium version the tests actually use. This can lead to protocol mismatches between the WebDriver client and the containerized Selenium.

Solutions

Run 'mvn dependency:tree' or 'gradle dependencies' to find duplicate selenium-api versions and exclude the transitive one.
Align all Selenium dependencies to a single version via dependencyManagement / a BOM.
Pin the Selenium Docker image explicitly so the ambiguous detection result does not matter.

Example fix

// before
// multiple selenium-api versions on classpath (3.141.59 via old dep, 4.10.0 direct)
// after
<dependency>
  <groupId>org.seleniumhq.selenium</groupId>
  <artifactId>selenium-api</artifactId>
  <version>4.10.0</version>
</dependency>
<!-- plus exclusions on transitive selenium deps -->

Defensive patterns

Strategy: validation

Validate before calling

Set<String> versions = seleniumVersionsOnClasspath(); // scan selenium-api jar manifests
if (versions.size() > 1) {
    throw new IllegalStateException("Multiple Selenium versions on classpath: " + versions);
}

Prevention

Run dependency:tree / gradle dependencies to detect duplicate selenium-api versions
Exclude transitive Selenium 3 deps from legacy libraries
Use a Selenium BOM to align versions; pin the Docker image explicitly

When it happens

Trigger: Having multiple selenium-api jars of different versions on the classpath (e.g. selenium-api 3.x pulled transitively alongside 4.x) and calling determineClasspathSeleniumVersion().

Common situations: Legacy Selenium 3 dependencies leaking in via transitive deps; multiple test frameworks (Selenide, Serenity) bundling different Selenium versions; dependency conflicts unresolved in Gradle/Maven.

Understand the failure class

Background: Conflicting config options: "cannot be used together" — configuration validation errors across open-source libraries — this error's family across 162 libraries.

Related errors

AI-assisted analysis of testcontainers/testcontainers-java@8e549514e3 (2026-09-12). Data as JSON: /api/errors/dbda31a3b45dbfb7. Report an issue: GitHub.

Appendix: source

Thrown at modules/selenium/src/main/java/org/testcontainers/containers/SeleniumUtils.java:62

                        LOGGER.info("Selenium API version {} detected on classpath", seleniumVersion);
                    }
                }
            }
        } catch (Exception e) {
            LOGGER.debug("Failed to determine Selenium-Version from selenium-api JAR Manifest", e);
        }

        if (seleniumVersions.size() == 0) {
            LOGGER.warn(
                "Failed to determine Selenium version from classpath - will use default version of {}",
                DEFAULT_SELENIUM_VERSION
            );
            return DEFAULT_SELENIUM_VERSION;
        }

        String foundVersion = seleniumVersions.iterator().next();
        if (seleniumVersions.size() > 1) {
            LOGGER.warn(
                "Multiple versions of Selenium API found on classpath - will select {}, but this may not be reliable",
                foundVersion
            );
        }

        return foundVersion;
    }

    /**
     * Read Manifest to get Selenium Version.
     * @param manifest manifest
     * @return Selenium Version detected
     */
    public static String getSeleniumVersionFromManifest(Manifest manifest) {
        String seleniumVersion = null;
        Attributes buildInfo = manifest.getAttributes("Build-Info");
        if (buildInfo != null) {
            seleniumVersion = buildInfo.getValue("Selenium-Version");

View on GitHub (pinned to 8e549514e3)