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
- Align all Dubbo artifact versions using dubbo-bom in dependencyManagement.
- Inspect `mvn dependency:tree` for transitive dubbo-* jars at divergent versions and exclude/align them.
- If forking Dubbo and adding a scope value, add a matching case to this switch.
- 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
- Pin all Dubbo artifacts to a single version with dubbo-bom.
- Audit dependency:tree for mismatched dubbo-* versions.
- Do not mix vendor-shaded Dubbo jars.
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
- Unable to get default scope model for type: ${type.getName()
- ExtensionLoader for [${type}] is not found
- No activate extensions for [${type}] found
- There is no merger to merge result.
- No such class name in {}
AI-assisted analysis of apache/dubbo@3a3043227f (2026-08-14).
Data as JSON: /api/errors/32aff11d57b1ddf2.
Report an issue: GitHub.