zengbohan1 commented on issue #12637: URL: https://github.com/apache/dubbo/issues/12637#issuecomment-5423588921
I reproduced this on the latest **3.3.6** (release) using the demo from @aishang1993, so this is still unresolved on the current 3.3 line. **Reproduction** (demo: https://github.com/aishang1993/dubbo3-issue-12637, with 3 adjustments for 3.3.x: bump dubbo.version to 3.3.6, replace the removed `dubbo-dependencies-zookeeper-curator5` pom with `dubbo-registry-zookeeper` + `dubbo-remoting-zookeeper-curator5`, and change `dubbo.protocol.serialization` from `java` to `fastjson2`): ``` BeanCreationException: Error creating bean with name 'demo1Controller': Injection of resource dependencies failed; Caused by: BeanNotOfRequiredTypeException: Bean named 'demo1Service' is expected to be of type 'com.example.dubbodemo.Demo1Service' but was actually of type 'com.example.dubbodemo.Demo2ServiceDubboProxy0' ``` **Root cause — a cross-annotation collision that the existing rename guard cannot cover:** 1. `Demo2Controller` has `@DubboReference private Demo2Service demo1Service`. `ReferenceAnnotationBeanPostProcessor.registerReferenceBean` registers a ReferenceBean under the **field name** `demo1Service` (a Demo2Service proxy). 2. `Demo1Controller` has `@Resource private Demo1Service demo1Service`. `CommonAnnotationBeanPostProcessor` resolves `@Resource` **by name first**, finds the Demo2Service proxy registered above, and the type check fails. The rename logic in `registerReferenceBean` (3.3 branch, the `rename dubbo reference bean to [xxx#2]` branch) only guards **@DubboReference vs @DubboReference** collisions: it checks `containsBeanDefinition`/aliases at registration time. A `@Resource` field registers no bean definition and is resolved later, so from the processor's point of view the name `demo1Service` was free when `Demo2Controller` was processed — bean-creation order decides which side explodes. As @huogithub analyzed above, 2.7.x behaved differently in `registerReferenceBean` (provider instance + alias for consumers), which is why this did not happen before 3.x. **Fix directions — since any naming change is breaking, I'd like the team's preference before writing code:** 1. **Non-breaking mitigation**: when a `@DubboReference`-registered bean name is later resolved by another injector with an incompatible type we cannot intercept Spring's `@Resource` path, so a clean non-breaking fix seems hard. The best non-breaking option I can see is startup-time detection/warning, which only softens the failure. 2. **Breaking (master/3.4)**: change the default reference bean name for id-less `@DubboReference` from the raw field name to a deterministic name derived from the reference key (interface/group/version), with a compatibility switch (e.g. `dubbo.application.reference-bean-naming-strategy=field-name`) to restore the old behavior. Happy to implement either — please advise which direction the team prefers. Thanks! -- 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]
