Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## 3.3 #16144 +/- ##
============================================
- Coverage 60.80% 60.78% -0.02%
+ Complexity 11756 11755 -1
============================================
Files 1953 1953
Lines 89118 89118
Branches 13444 13444
============================================
- Hits 54188 54173 -15
- Misses 29368 29377 +9
- Partials 5562 5568 +6
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
In this mode, ensure that invoker.getInterface() (i.e., GenericService) is placed at the forefront. |
9ea4b02 to
fd5e89a
Compare
|
this pr might cause problem if the dubbo generice service references are created without annotation |
It seems that the only scenario where the interface order of AbstractProxyFactory needs to take effect for Spring is when users entirely bypass ReferenceBean and directly call referenceConfig.get() in a @bean method—which is precisely the case this PR aims to fix. |
|
It seems that scenarios without @bean won't cause issues either, because those cases are protected by the lazy proxy layer. |
e0b8494 to
fd5e89a
Compare
|
@zrlw I looked into this concern. This change only reorders two code blocks — the final set of interfaces the proxy implements stays exactly the same, just the iteration My understanding is that for references created without @bean (via @DubboReference or XML), Spring resolves bean type through ReferenceBean.getObjectType(), which As for why the reorder helps the @bean case: Javassist Proxy.getProxy() uses ics[0].getClassLoader() to create the proxy class. Before this change, ics[0] was the Would love to hear your thoughts — happy to adjust the approach if there are cases I haven't considered. |
What is the purpose of the change?
Close #16083
Checklist