xiaolongzuo opened a new issue, #15675: URL: https://github.com/apache/dubbo/issues/15675
### Pre-check - [x] I am sure that all the content I provide is in English. ### Search before asking - [x] I had searched in the [issues](https://github.com/apache/dubbo/issues?q=is%3Aissue) and found no similar issues. ### Apache Dubbo Component Java SDK (apache/dubbo) ### Dubbo Version dubbo:2.7.x jdk:jdk8 spring boot: 1.5.22 ### Steps to reproduce this issue My scenario is that I want to build a plugin mechanism, which I’ll refer to as the base and plugins. Both the base and plugins are Spring fat JARs, and both contain Dubbo interfaces (including both providers and consumers). I want to isolate them using class loader mechanisms. However, I’ve encountered an issue: when loading a plugin, DubboConfigConfigurationRegistrar eventually calls AnnotatedBeanDefinitionRegistryUtils.isPresentBean during registration. The problem is that isPresentBean checks whether all beans in the Spring context can be properly loaded, and inside this method, it uses annotatedClass.getClassLoader() instead of the current thread context class loader. As a result, if Dubbo-related classes in the plugin are supposed to be loaded by the base’s class loader, the plugin’s classes cannot be found, which causes errors — for example, PluginSpringApplication cannot be loaded. This is inevitable because the base’s class loader obviously cannot see the classes inside the plugin. On the other hand, if I choose to let the plugin’s class loader load its own Dubbo classes — meaning there are two completely isolated sets of Dubbo classes in the JVM — then various ClassCastException issues occur because the Dubbo types from the base and the plugin are incompatible. So my question is: was there a specific reason for using annotatedClass.getClassLoader() here instead of the thread context class loader? ### What you expected to happen Ideally, I expect to have only one set of Dubbo classes. That is, I want the plugin’s class loader to adopt a parent-first delegation model: whenever a class already exists in the base, it should directly use the base’s class. This approach would avoid a lot of class conversion issues. However, this leads to the problem I mentioned earlier: during Dubbo’s initialization, it iterates through all Spring beans to check whether their classes can be properly loaded. As a result, the base’s class loader attempts to load the plugin’s classes, which it naturally cannot find, causing a ClassNotFoundException. (This is expected, since the base class loader simply has no visibility into the plugin classes.) ### Anything else _No response_ ### Are you willing to submit a pull request to fix on your own? - [ ] 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) -- 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: notifications-unsubscr...@dubbo.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@dubbo.apache.org For additional commands, e-mail: notifications-h...@dubbo.apache.org
