Pre-check
Component
Java SDK (apache/dubbo)
Descriptions
Background
When troubleshooting SPI extension loading issues in development or testing environments (e.g., version conflicts causing certain extensions not to be loaded, or unexpected wrapper chains), the only way to observe what ExtensionLoader actually loaded is by attaching remote debugging tools like Arthas. This significantly increases the diagnosis cost.
In our organization, we maintain numerous internal Dubbo SPI components across many different versions, along with a custom class-isolation framework. We frequently encounter situations where package version conflicts cause SPI extensions to fail to load silently. Currently, the only way to investigate these issues is by attaching Arthas at runtime to inspect the loaded classes, which is time-consuming and error-prone.
Proposal
Add DEBUG-level logging to key stages of ExtensionLoader so that users can observe SPI loading behavior by simply enabling DEBUG for org.apache.dubbo.common.extension.ExtensionLoader, without any code changes or remote tools.
The proposed log points cover:
- Extension classes loading — start/finish with timing, loaded extension names, adaptive class, wrapper classes
- Extension instance creation — which implementation class was instantiated, which wrappers were applied
- Skipped inactive extensions — which
@Activate(onClass=...) dependencies are missing (refactored loadClassIfActive to findMissingOnClass to return the missing class names for diagnostic logging)
- Each SPI class loaded — class type (adaptive/wrapper/extension), names, source resource URL
All logs are at DEBUG level with isDebugEnabled() guards, zero overhead in production when DEBUG is not enabled.
Example output
DEBUG - Start loading extension classes, type=com.example.MyExt, scopeModel=..., defaultName=impl1
DEBUG - Loaded SPI extension class, type=com.example.MyExt, names=[impl1], class=com.example.MyExtImpl1, resourceURL=...
DEBUG - Loaded SPI wrapper class, type=com.example.MyExt, names=[], class=com.example.MyExtWrapper, resourceURL=...
DEBUG - Finished loading extension classes, type=com.example.MyExt, count=2, adaptiveClass=null, wrapperClasses=[...], names=[impl1, impl2], costInMillis=3
DEBUG - Loaded extension instance, type=com.example.MyExt, name=impl1, instanceClass=com.example.MyExtWrapper, wrap=true, wrapperClasses=[com.example.MyExtWrapper]
DEBUG - Skip inactive extension class, type=com.example.MyExt, class=com.example.InactiveImpl, missingOnClass=[com.missing.Dependency]
Are you willing to submit a pull request on your own?
Code of Conduct
Pre-check
Component
Java SDK (apache/dubbo)
Descriptions
Background
When troubleshooting SPI extension loading issues in development or testing environments (e.g., version conflicts causing certain extensions not to be loaded, or unexpected wrapper chains), the only way to observe what
ExtensionLoaderactually loaded is by attaching remote debugging tools like Arthas. This significantly increases the diagnosis cost.In our organization, we maintain numerous internal Dubbo SPI components across many different versions, along with a custom class-isolation framework. We frequently encounter situations where package version conflicts cause SPI extensions to fail to load silently. Currently, the only way to investigate these issues is by attaching Arthas at runtime to inspect the loaded classes, which is time-consuming and error-prone.
Proposal
Add DEBUG-level logging to key stages of
ExtensionLoaderso that users can observe SPI loading behavior by simply enabling DEBUG fororg.apache.dubbo.common.extension.ExtensionLoader, without any code changes or remote tools.The proposed log points cover:
@Activate(onClass=...)dependencies are missing (refactoredloadClassIfActivetofindMissingOnClassto return the missing class names for diagnostic logging)All logs are at DEBUG level with
isDebugEnabled()guards, zero overhead in production when DEBUG is not enabled.Example output
Are you willing to submit a pull request on your own?
Code of Conduct