apache/dubbo · error · IllegalArgumentException

Unable to get ExtensionLoader for type: ${type.getName()}

Error message

Unable to get ExtensionLoader for type: ${type.getName()}

What it means

The default branch of the switch over spi.scope() inside getExtensionLoader(). SPI.Scope is a fixed enum (FRAMEWORK/APPLICATION/MODULE) and all values are cased, so this branch is only reachable if a new enum constant exists that this build does not recognize — i.e. a classpath with mismatched Dubbo versions where one module knows of a scope the common module does not.

Source

Thrown at dubbo-common/src/main/java/org/apache/dubbo/rpc/model/ScopeModelUtil.java:116

    }

    public static <T> ExtensionLoader<T> getExtensionLoader(Class<T> type, ScopeModel scopeModel) {
        if (scopeModel != null) {
            return scopeModel.getExtensionLoader(type);
        } else {
            SPI spi = type.getAnnotation(SPI.class);
            if (spi == null) {
                throw new IllegalArgumentException("SPI annotation not found for class: " + type.getName());
            }
            switch (spi.scope()) {
                case FRAMEWORK:
                    return FrameworkModel.defaultModel().getExtensionLoader(type);
                case APPLICATION:
                    return ApplicationModel.defaultModel().getExtensionLoader(type);
                case MODULE:
                    return ApplicationModel.defaultModel().getDefaultModule().getExtensionLoader(type);
                default:
                    throw new IllegalArgumentException("Unable to get ExtensionLoader for type: " + type.getName());
            }
        }
    }
}

View on GitHub (pinned to 3a3043227f)

Solutions

  1. Align all Dubbo artifact versions using dubbo-bom in dependencyManagement.
  2. Inspect `mvn dependency:tree` for transitive dubbo-* jars at divergent versions and exclude/align them.
  3. If forking Dubbo and adding a scope value, add a matching case to this switch.
  4. Upgrade the conflicting module to the version of dubbo-common in use.

Example fix

// not user-code; resolve dependency versions
// before: dubbo-common 3.0.x + dubbo-rpc 3.2.x (new scope constant)
// after: pin all to one version via dubbo-bom (see error 368 example)
Defensive patterns

Strategy: validation

Validate before calling

Set<String> known = Set.of("FRAMEWORK", "APPLICATION", "MODULE");
for (SPI.Scope s : SPI.Scope.values()) {
    if (!known.contains(s.name())) {
        throw new IllegalStateException("Unsupported SPI.Scope " + s + " — align Dubbo versions");
    }
}

Prevention

When it happens

Trigger: Same root cause as error 368: a SPI.Scope enum value not handled by the switch, only reached through the extension-loader path. Requires mixed/incompatible Dubbo artifact versions or a fork that added a scope constant without updating this switch.

Common situations: Dependency version conflicts across dubbo-* artifacts (e.g. dubbo-common older than dubbo-rpc). Shaded jars from different vendors. A custom Dubbo fork that extended SPI.Scope. Practically unreachable in a consistent-version deployment.

Related errors


AI-assisted analysis of apache/dubbo@3a3043227f (2026-08-14). Data as JSON: /api/errors/32aff11d57b1ddf2. Report an issue: GitHub.