GoogleContainerTools/jib · error · UnsupportedOperationException

Computing the entrypoint is currently not supported.

Error message

Computing the entrypoint is currently not supported.

What it means

StandardWarExplodedProcessor represents an exploded WAR, which must be deployed into a servlet container rather than run via `java -jar`. Its computeEntrypoint is intentionally unimplemented and always throws UnsupportedOperationException.

Source

Thrown at jib-cli/src/main/java/com/google/cloud/tools/jib/cli/war/StandardWarExplodedProcessor.java:122

    if (!nonSnapshotLayer.getEntries().isEmpty()) {
      layers.add(nonSnapshotLayer);
    }
    if (!snapshotLayer.getEntries().isEmpty()) {
      layers.add(snapshotLayer);
    }
    if (!resourcesLayer.getEntries().isEmpty()) {
      layers.add(resourcesLayer);
    }
    if (!classesLayer.getEntries().isEmpty()) {
      layers.add(classesLayer);
    }

    return layers;
  }

  @Override
  public ImmutableList<String> computeEntrypoint(List<String> jvmFlags) {
    throw new UnsupportedOperationException("Computing the entrypoint is currently not supported.");
  }

  @Override
  public Integer getJavaVersion() {
    throw new UnsupportedOperationException(
        "Getting the java version from a WAR file is currently not supported.");
  }
}

View on GitHub (pinned to fb949e2676)

Solutions

1. Deploy the WAR by using a servlet-container base image (Tomcat/Jetty) and copying the WAR into the deploy directory instead of relying on Jib's JAR entrypoint computation
2. Use a Jib extension/base-image approach that supplies an explicit entrypoint
3. Convert the project to an executable JAR (spring-boot executable jar or similar) if a standalone entrypoint is required

Example fix

// before
Containerizer.to(RegistryImage.named("img")).setApplication(war)  // WAR treated like JAR
// after
Use base image tomcat:9 and addEntrypoint/ WAR copied to /usr/local/tomcat/webapps

if (app instanceof WarProcessor || appFile.getName().endsWith(".war")) { /* use servlet container base image; do not call computeEntrypoint */ }

boolean supportsEntrypoint(JibProcessor p) { return !(p instanceof StandardWarExplodedProcessor); }

try { ep = processor.computeEntrypoint(flags); } catch (UnsupportedOperationException e) { ep = defaultServletContainerEntrypoint; }

When it happens

Trigger: Any call to computeEntrypoint on an exploded-WAR processor — e.g. Jib's JAR/WAR processing pipeline invoking entrypoint computation for a WAR input.

Common situations: Pointing Jib CLI/Core at a WAR file or exploded WAR directory expecting Java-app entrypoint handling; using WAR inputs with flows that assume JAR semantics.

Related errors

• Getting the java version from a WAR file is currently not su
• mainClass, extraClasspath, jvmFlags, and expandClasspathDepe
• Please set the app root of the container with `--app-root` w
• `Main-Class:` attribute for an application main class not de
• `Main-Class:` attribute for an application main class not de

AI-assisted analysis of GoogleContainerTools/jib@fb949e2676 (2026-09-06). Data as JSON: /api/errors/ea3cd084ca25e4e1. Report an issue: GitHub.