[Feature] Add DEBUG-level logs for SPI extension loading in ExtensionLoader
- Dominant language
- Java
- Stars
- 41.6k
- Forks
- 26.4k
- Avg merge
- 15h 13m
- Merged PRs (30d)
- 4
Description
### Pre-check
- [x] I am sure that all the content I provide is in English.
- [x] I had searched in the [issues](https://github.com/apache/dubbo/issues?q=is%3Aissue) and found no similar feature requirement.
### 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:
1. **Extension classes loading** — start/finish with timing, loaded extension names, adaptive class, wrapper classes
2. **Extension instance creation** — which implementation class was instantiated, which wrappers were applied
3. **Skipped inactive extensions** — which `@Activate(onClass=...)` dependencies are missing (refactored `loadClassIfActive` to `findMissingOnClass` to return the missing class names for diagnostic logging)
4. **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?
- [x] Yes I am willing to submit a pull request on my own!
### Code of Conduct
- [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct)
Contributor guide
Research direction
Start by locating org.apache.dubbo.common.extension.ExtensionLoader and reading its extension-class loading, instance creation, and loadClassIfActive paths. Check how loadClassIfActive can become findMissingOnClass and identify existing logging and test conventions nearby. Done means DEBUG-guarded diagnostics cover loading, instantiation, inactive extensions, and SPI resource details without changing behavior when DEBUG is disabled.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- backend, distributed-systems
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100