obabichevjb opened a new pull request, #16494:
URL: https://github.com/apache/dubbo/pull/16494
## What is the purpose of the change?
Fixes #16493.
`ServiceConfigBase.checkRef` exists to report a service whose `ref` does not
implement the declared
interface:
```
The class <impl> unimplemented interface <itf>!
```
Its message is built by `getClassDesc`, which dereferences
`Class#getClassLoader()`. That returns
**null for any bootstrap-loaded class** — every JDK type — so when a JDK
type is on either side of
the mismatch the check throws from inside its own diagnostic:
```
java.lang.NullPointerException: Cannot invoke "Object.getClass()" because
"classLoader" is null
at
org.apache.dubbo.config.ServiceConfigBase.getClassDesc(ServiceConfigBase.java:162)
at
org.apache.dubbo.config.ServiceConfigBase.checkRef(ServiceConfigBase.java:156)
at
org.apache.dubbo.config.ServiceConfig.checkAndUpdateSubConfigs(ServiceConfig.java:508)
...
at
org.apache.dubbo.config.bootstrap.DubboBootstrap.start(DubboBootstrap.java:219)
```
The real misconfiguration is never reported, and the NPE surfaces during
application start, several
frames from the config that caused it, naming neither the service nor the
interface.
A mismatch between two user-defined types already reports correctly, because
their loader is
non-null. Only a JDK type on either side hits this.
## Brief changelog
- `getClassDesc` renders a null loader as `[classloader=bootstrap]` instead
of dereferencing it.
The loader stays in the message, because the same class name under two
different loaders is a real
and confusing failure mode worth naming.
- Two tests in `ServiceConfigTest` covering both paths. `checkRef` had no
test coverage at all.
## Verifying this change
- Without the fix,
`testCheckRefReportsUnimplementedInterfaceForBootstrapLoadedType` fails with
exactly the reported NPE, so the test is not vacuous. The user-type test
passes either way, which
is what pins the scope.
- With it, the same configuration produces
`The class ...GreeterServiceImpl[classloader=...AppClassLoader@746933701]
unimplemented interface java.lang.Runnable[classloader=bootstrap]!`
- `dubbo-common`: 1165 tests, 0 failures. `dubbo-config-api`: 697 tests, 0
failures.
`mvn spotless:check` passes on both.
- Verified end-to-end against a locally built jar, not just in unit tests.
The `main` quoted in the
issue was run as-is against 3.3.6 and against this branch, and goes from
the bare NPE to
`The class ...GreeterServiceImpl[classloader=...AppClassLoader@746933701]
unimplemented interface java.lang.Runnable[classloader=bootstrap]!`
## Does this pull request potentially affect one of the following parts?
- Dependencies: no.
- Public API: no — `getClassDesc` is private, and the only observable change
is the text of an
exception that previously could not be produced at all in this case.
## Checklist
- [x] Make sure there is a
[GitHub_issue](https://github.com/apache/dubbo/issues) field for the change. —
#16493
- [x] Write a pull request description that is detailed enough to understand
what the pull request does, how, and why.
- [x] Write necessary unit-test to verify your logic correction. If the new
feature or significant change is committed, please remember to add sample in
[dubbo samples](https://github.com/apache/dubbo-samples) project. — two tests
in `ServiceConfigTest`, covering the bootstrap-loaded and user-loaded paths.
- [x] Make sure gitHub actions can pass. [Why the workflow is failing and
how to fix it?](../CONTRIBUTING.md)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
